Providing Offers and Associated Location Information

ABSTRACT

Provided is a process, including: obtaining a coupon issued by a merchant, the coupon being redeemable in-store, at a physical location of the merchant; obtaining one or more merchant location identifiers, the coupon only being redeemable at one or more merchant locations identified by the one or more merchant location identifiers; sending the coupon and the merchant location identifiers to publishers for presentation to consumers by the publishers on user devices of the consumers; and receiving indications from the user devices of the consumers that the consumers interacted with the coupon, the indications indicating a consumer selection of an in-store redemption option.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patentapplication 61/894,329, filed 22 Oct. 2013, and having the same title asthis filing. Each parent filing is hereby incorporated by reference inits entirety for all purposes.

BACKGROUND

1. Field

The present invention relates generally to offers and, morespecifically, to systems for electronically tracking offers having offerlocation data.

2. Description of the Related Art

Often merchants enlist third parties to promote offers, such as coupons,sales, rebates, favorable shipping terms, or other changes in termsfavorable to consumers. This practice in recent years has expandedgreatly in the context of the Internet. In some cases, a given offer maybe distributed by thousands of publishers on the World Wide Web (orother content-publishing platforms, such as those having nativeapplications on mobile devices) to millions of consumers. Each publishermay draw an audience based on content gathered, curated, or created bythat publisher, and merchants may compensate a publisher for presentingthe merchant's offers to that publisher's audience. Consequently,consumers become aware of potentially valuable offers; merchants benefitfrom wide distribution of their offers; and publishers are compensatedfor providing content valued by their audience.

Generally, merchants seek wide distribution of their offers to largenumbers of publishers and consumers, in some cases according togeographic or publisher-type constraints consistent with a merchant'sbrand and geographic reach. But managing a large network of publishersis difficult and expensive. For instance, simply determiningcompensation can be challenging at large scales. Often, publishers arecompensated based on revenue that is received by the merchant fromvisitors to the publishers website or other application, and keepingtrack of which publishers should be credited for which transactions canbe very expensive, particularly when a merchant wishes to work withthousands of publishers potentially leading to millions of transactions.Further, selecting, communicating with, and establishing contractualrelationships with thousands of publishers can be expensive, complex,and labor intensive.

Similarly, many publishers wish to work with a relatively large numberof merchants in order to receive a relatively large number of offers topresent to the publishers' audiences. Yet many publishers lack theresources to track, across hundreds of merchants, which offers led tocompensable consumer actions or establish contractual relationships withhundreds of merchants, let alone accommodate a potentially diverse setof merchant-specific protocols and business processes for communicatinginformation about offers.

To shield both merchants and publishers from this complexity, manyon-line offers are distributed through affiliate-network systems. Thesecomputer systems act as an intermediary between publishers andmerchants, distributing offers to publishers, allocating credit topublishers for revenue they generate for merchants, simplifying theprocess of establishing contractual relationships, and standardizingcommunication protocols and business processes. (Though not allaffiliate-network systems necessarily fill all of these roles.) Oftenmerchants and publishers access these computer systems throughrole-specific interfaces presented over the Internet, or access may beprovided via a human representative of the entity operating theaffiliate-network system who updates the system on behalf of merchantsor publishers.

Many affiliate-network systems are ill-suited to address future trendsin the distribution of offers expected by applicants. As smart phonesand other mobile user devices proliferate, it is becoming increasinglyviable and desirable to present and redeem offers both on-line, when theconsumer is away from (or not necessarily at) the geographic location ofa merchant's brick-and-mortar store, and in-store, when the consumer isphysically present at a merchant's location. Further, as consumersintegrate more networked devices and network-accessible accounts intotheir lives, many consumers wish to distribute offer discovery, offercuration, and offer redemption across multiple electronic devices andaccounts, with activities through one device or account being reflectedin other devices or accounts. Yet many traditional affiliate-networksystems are not configured to track these activities both on-line andoff-line (e.g., in-store or through a different device or account fromthat through which the publisher initially presented the offer). As aconsequence, these traditional systems are ill-suited to properlycompensate publishers, distribute offers through multiple on-line andoff-line channels, or provide merchants and publishers with analyticsand controls spanning multiple channels.

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a process, including: obtaining a coupon issued bya merchant, the coupon being redeemable in-store, at a physical locationof the merchant and obtaining one or more merchant location identifiers,the coupon only being redeemable at one or more merchant locationsidentified by the one or more merchant location identifiers. The processfurther includes sending the coupon and the merchant locationidentifiers to publishers for presentation to consumers by thepublishers on user devices of the consumers and receiving indicationsfrom the user devices of the consumers that the consumers interactedwith the coupon, the indications indicating a consumer selection of anin-store redemption option. The process may include, after an indicationthat a given consumer interacted with the coupon, effectuatingoperations including: sending the given consumer redemption datadocumenting that the given consumer is in possession of the coupon forpresentation to the merchant at a physical location of the merchant, thedata identifying a first publisher that presented the coupon to thegiven consumer to credit first publisher; receiving transaction datafrom the merchant indicating that the given consumer redeemed thecoupon; determining compensation for the first publisher based on thetransaction data.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by a data processing apparatuscause the data processing apparatus to perform operations including theabove-mentioned process.

Some aspects include a system, including: one or more processors; andmemory storing instructions that when executed by the processors causethe processors to effectuate operations of the above-mentioned process.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following FIGS. in which like numbers indicate similar oridentical elements:

FIG. 1 shows a computing environment having an example of anaffiliate-network system in accordance with some embodiments;

FIGS. 2 through 6 show an example of a process for distributing offersredeemable both on-line and off-line in accordance with someembodiments;

FIG. 7 shows an example of offer content that is dynamically configuredfor presentation on a user device having a relatively large display;

FIG. 8 shows an example of offer content that is dynamically configuredfor presentation on a mobile user device having a relatively smalldisplay;

FIG. 9 shows an example of a merchant-analytics interface that presentsdata aggregated across multiple channels of offer interaction;

FIGS. 10A and 10B each show portions of an example of apublisher-analytics interface that presents data aggregated acrossmultiple channels of offer interaction;

FIG. 11 shows an example of a process for dynamically adjusting theterms of multi-channel offers based on feedback from multiple channelsof offer interaction;

FIG. 12 shows an example of a process for providing merchant locationsand offers to an affiliate-network system;

FIG. 13 shows an example of a process for providing using offers andoffer location data;

FIG. 14 shows an example of a consumer user device displaying offers ona computer-implemented geographic map;

FIG. 15 shows an example of a process for processing merchant locationsprovided by a merchant system;

FIG. 16 shows an example of a process for offer feedback using offerlocation data;

FIG. 17 shows an example of a process for identifying merchant breakage;and

FIG. 18 shows an example of a computing system by which theabove-mentioned systems, devices, and processes may be implemented.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit theinvention to the particular form disclosed, but to the contrary, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the present invention as definedby the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

FIG. 1 shows a computing environment 10 having an embodiment of anaffiliate-networking system 12. The illustrated system 12, in someimplementations, mitigates the above-mentioned problems with traditionalaffiliate-network systems, problems that, as noted, are particularlyacute when existing systems are applied to offers redeemable bothin-store and on-line. To mitigate these problems, the applicants had toboth invent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field.Indeed, applicants wish to emphasize the difficulty of recognizing thoseproblems that are nascent and will become much more apparent in thefuture should trends in the affiliate-networking industry continue asapplicants expect. Further, because multiple problems are addressed, itshould be understood that some embodiments are problem-specific, and notall embodiments address every problem with traditional systems describedherein. That said, solutions to many of these problems are describedwith reference the affiliate-networking system 12 of FIG. 1.

In some embodiments, the affiliate-network system 12 is configured todistribute and track offers that are (for some offers) each redeemableon-line and off-line, which includes in-store redemption and redemptionthrough other devices or accounts:

-   -   a. To accommodate the different display capabilities of various        accounts and devices, some embodiments receive, from a merchant,        and implement specifications for an offer that define, at least        in part, how the offer is to be displayed in each of a variety        of different modes of presentation, such as on a desktop        computer web browser, on a tablet computer native application,        on a smart phone, in print, in email, and in short message        service text messages, to name a few examples.    -   b. To facilitate tracking, some embodiments host offer content        that publishers embed in their websites, native applications, or        other publisher content. In some cases, the offer content        returns to the affiliate-network system user interactions with        offers (e.g., selections of buttons and the like) that may be        tracked both when the user pursues on-line redemption and        off-line redemption.    -   c. To reduce the complexity of managing multi-channel offers for        merchants, publishers, and consumers, some embodiments store        data about an offer with reference to a single offer record,        such that multiple forms of interaction and presentation are        readily tracked, configured, or otherwise managed, with        reference to the single record.    -   d. To reduce complexity for those distributing offers, some        embodiments are configured to provide multi-channel access to an        offer through a single uniform resource identifier (URI)        corresponding to the offer, such that a request for offer        content identifying the URI (e.g., when a consumer's web browser        encounters the URI embedded in a publisher's website) yields        offer content configured according to the type of device or        account to which the offer content is directed. Using a single        URI for differently formatted presentation of an offer is        expected to simplify offer management for both consumers and        publishers, as format-specific URI need not be tracked by these        parties.    -   e. To facilitate tracking of multi-channel offers, some        embodiments are configured to provide analytics to both        merchants and publishers that aggregate both on-line and        off-line consumer interactions, such as redemptions.    -   f. To facilitate control of multi-channel offers, some        embodiments execute routines specified by merchants for        dynamically adjusting the terms of offers based on feedback from        multiple channels of offer redemption, including on-line and        in-store redemptions.

Thus, some embodiments of the affiliate-network system 12 address avariety of different problems associated with the use of offers that areredeemable both on-line and in-store. Each of these solutions, however,need not be included in every embodiment, as some embodiments mayaddress only some of the above-described problems with existingaffiliate-network systems, which is not to suggest that any otherfeature described herein may not also be omitted in some embodiments.

Operation of the affiliate-network system 12 is better understood inview of the other components of the computing environment 10 with whichthe system 12 interacts. As illustrated by FIG. 1, embodiments includethe Internet 14, merchant systems 16, publisher servers 18, and consumeruser devices 20. The components of the computing environment 12 connectto one another through the Internet 14 and various other networks, insome cases, such as cellular networks, local area networks, wirelessarea networks, and the like. While three of each component 16, 18, and20 are illustrated, it should be understood that embodiments withsubstantially more of these devices are contemplated. For example,likely applications include tens of millions of consumer user devices20, tens of thousands of publisher servers 18, and hundreds or thousandsof merchant systems 16.

The illustrated merchant systems 16 may each correspond to a differentmerchant and may each include a variety of different types of computingdevices used by the respective merchants in the course of business.Merchant systems 16 may include merchant web servers that host merchantwebsites. In some cases, it is the merchant websites to which consumeruser devices 20 are directed for on-line redemption of offers and toview goods or services associated with offers. Merchant systems 16 mayalso include user devices of merchant employees that interact with theaffiliate-network system 12 to configure new offers, reconfigureexisting offers, view analytics associated with offers and publishers,and otherwise control offers issued by the respective merchant. Merchantsystems 16 may also include point-of-sale terminals and electronickiosks located at the physical sites of the respective merchant, such asat retail stores or service centers. Systems 16 may also includemerchant databases connected to those point-of-sale terminals forstoring financial-transaction records associated with transactions with,e.g., sales to, consumers. The merchant systems 16 may be configured toautomatically, or at the direction of the merchant's employees, uploadtransaction records from the merchant's database to theaffiliate-network system 12. These uploaded transaction records, in someembodiments, are used to determine compensation for publishers based onin-store redemptions of offers by consumers, the compensation rewardingpublishers who potentially made the consumers aware of the offers asindicated by records in the affiliate-network system 12. Often, merchantsystems 16 are geographically distributed, for example, havingpoint-of-sale terminals in multiple stores of a retail chain, and havinga merchant database and employee user devices in a central office of therespective merchant.

The publisher servers 18, in some embodiments, serve publisher content(e.g., web pages, data for display with a native application on a mobiledevice, set-top box, in-store kiosk, or the like). In some cases, thepublisher content is served to consumer user devices 20 and includesinstructions to retrieve and display offer content from theaffiliate-network system 12. In some cases, the offer content isembedded in the publisher's content, e.g., with URI's in a publisher'swebpage that cause a web browser to retrieve and embed content from theaffiliate-network system 12 bracketed with an HTML “embed” tag, ani-frame, or other instructions that cause content from outside thepublisher's domain to be displayed. In some cases, the offer content isnot embedded and is referenced by linking or re-directing to theaffiliate-network system 12. Or, in some cases, the publisher servers 18serve offer content directly to consumer user devices 20.

The publisher content, in some cases, is web content, like websiteshaving webpages in which multiple offers are referenced or included. Insome cases, consumers seek out the websites of publishers because thepublishers curate offers on behalf of the consumers (e.g., selectingoffers based on quality, success rate, subject matter, or the like).Publisher servers 18 may provide, in the publisher content, interfacesby which consumers can share data indicative of the efficacy orapplicability of offers, for example, by indicating success rates foroffers, providing content or comments about offers, rating offers,categorizing offers, or up-voting or down-voting offers. In other cases,the publishers servers 18 host content that is not specific to offers,such as webpages about particular areas of interest, like sportinggoods, electronic devices, home goods, fashion, current events, or thelike, and the publishers includes links to offers curated with thatpublisher's audience in mind.

In other cases, the publisher servers 18 host a publisher applicationprogram interface (API) that services native applications on consumeruser devices 20 (which may include public devices, like kiosks). Forexample, some publishers may offer a (non-web-browser) nativeapplication on a smart phone or tablet that is down-loadable from auser-device maker's service for providing approved applications.Examples of such applications include barcode-scanning applications bywhich a user captures an image of a product barcode with a camera of theconsumer user device 20, and the application converts the image into aproduct stock-keeping unit (SKU), which is then submitted to thepublisher server 18 for retrieving offers related to the SKU to bedisplayed on the consumer user device 20.

In another example, the application includes an application specificallyfor viewing offers. In some cases, the native application may beconfigured to interact with a user account hosted by the publisherserver 18 (which may include a plurality of computing devices, such as auser profile database and offers database) by which the user can viewoffers that they previously designated as favorites or view offers thatfriends of the offer user (e.g., as registered in a social network towhich the server has access) have identified to the offer user. Suchnative applications for viewing offers may further include various toolsby which the user can readily view and navigate through a plurality ofoffers, for example, including searching tools, faceted search, andlists of curated offers. In some cases, the native application isconfigured to obtain a geographic location of the user device, forexample, with a GPS sensor or other location determining serviceaccessed by the operating system of the consumer user device, andrequest offers based on the geographic location from the publisherserver 18, such as in-store offers for merchant stores that are near(e.g., within a threshold distance to or ranked based on a location of)the consumer user device. In some cases, the offers satisfy variousother criteria, for example, corresponding to a user profile indicatingthe types of offers in which the user is likely to be interested. Inother cases, a native application on the consumer user device may serveany of a variety of other functions for the consumer, and that nativeapplication presents offers as advertisements to subsidize the cost ofproviding that service.

The consumer user devices 20 may be any of a variety of different typesof computing devices through which consumers access the Internet 14.Examples of such computing devices are described below with reference toFIG. 12. In some cases, a given consumer user device 20 is a smartphone, tablet computer, laptop computer, or desktop computer. Consumeruser devices 20 include a processor and memory and may execute anoperating system in which a web browser or native application executesfor viewing offers. In some cases, the consumer user device 20 is amobile user device, which includes a portable power supply, like abattery, a fuel cell, or a solar energy source, such that the consumercan carry the user device into a merchant's physical store for in-storeredemption. In some cases, such mobile user devices include a wirelessinterface, such as Bluetooth™, a near-field communication (NFC)interface, or a wireless area network interface, by which the consumeruser device exchanges information with the point-of-sale terminal aboutoffers being redeemed, such as an offer identifier. Further, in somecases, the mobile user device includes a display by which an identifierof the offer to be redeemed is presented and is entered into apoint-of-sale terminal, for instance, by a sales clerk viewing thedisplay and manually typing in the offer identifier (e.g., an offercode), or by the sales clerk scanning the display with a barcode scanneror an optical scanner. In other cases, the consumer user device is notmobile and includes a relatively large display, for example, a desktopcomputer or a set-top box connected to a television with a screen largerthan 10-inches measured diagonally. In some cases, consumer user devices20 include an application specifically for viewing offers (e.g., anative application executing on a set-top box, like a gaming console orstreaming media device) or include a web browser by which the usernavigates to a publisher's website for viewing offers and to amerchant's website for redeeming offers. Consumer user devices 20 may beany of a variety of types of electronic devices connected to theInternet 14 by which users are made aware of, store, or obtaininformation about offers, including smart watches, head-mounteddisplays, networked appliances (e.g., Internet-enabled refrigerators),or public computing devices, such as an in-store kiosk.

As noted above, in some cases, offer content viewed on consumer userdevices 20 is identified to consumers by publisher servers 18, but ishosted by the affiliate-network system 12. For example, publisherservers 18 may send consumer user devices 20 a webpage listing aplurality of offers, and each offer listing may include an instructionto the consumer user device 20 to retrieve offer content from theaffiliate-network system 12 corresponding to the offer, for example, aURI of the respective offer that directs the consumer user device 20 toretrieve content from the affiliate-network system 12. Offer content mayinclude various offer resources by which views of offers areconstructed, such as mark-up information, templates, images, offerterms, coupon codes, and interfaces for interacting with the offer(e.g., buttons and scripts executed when buttons are selected toeffectuate selected actions). The offer content may be hosted by theaffiliate-network system 12, rather than the publisher server 18, tofacilitate tracking of offer interactions (e.g., redemptions, sharing,printing, or sending to another device or account) across both on-lineand off-line redemption channels. Or, some embodiments host the offercontent on the publisher servers 18 instead of, or in addition to, theaffiliate-network system 12.

Thus, in some cases, the display of an offer on a consumer user device20 may be preceded by the consumer user device 20 requesting contentfrom the publisher server 18, receiving that content, determining thatthe content includes instructions to request offer content from theaffiliate-network system 12 on a different domain from the publisherserver 18, and executing those instructions, to retrieve the offercontent. In some cases, the instructions from the publisher server 18 torequest offer content do not specify the type of user device or type ofaccount in which the offer will be viewed. Rather, in some embodiments,a single instruction, such as a single URI per offer, is provided by thepublisher server 18 regardless of the type of consumer user device orthe account, thereby relieving publishers of the burden of maintainingmultiple, different instructions for a single offer for each of thevarious potential viewing options. In response, the consumer user device20 may request content according to this instruction, for example withthe URI. In response, the affiliate-network system 12 may determinebased on the request and, in some cases, additional information aboutthe consumer user device 20 or account, the appropriate offer contentfor the type of presentation in which the offer will be viewed orotherwise used.

In some embodiments, the affiliate-network system 12 includes a webserver 22, an API server 24, a controller 26, an affiliate-network datastore 28, a content-negotiation module 30, a dynamic-terms offercontroller 32, and an analytics module 34. These components areillustrated and described as discrete functional blocks, but it shouldbe understood that code or hardware by which this functionality isprovided may be subdivided, intermingled, conjoined, or otherwisedifferently arranged. Further, it should be understood that one or morecomputing devices, and in many embodiments, a plurality of computingdevices, by which this functionality is implemented may begeographically distributed or co-located, for example, in a dataprocessing facility. Further, it should be understood that some of thecomponents and features of the affiliate-network system 12 may beomitted in some embodiments, which is not to suggest that any otherfeature is required in all embodiments.

In some embodiments, the web server 22 is operative to receive requestsfrom web browsers executed by user devices of consumers, publishers, ormerchants. In some cases, those requests include requests for, orinteractions with, role-specific webpages, for consumers, publishers, ormerchants. For instance, a merchant may request a webpage for specifyinga new offer, viewing data about a previously specified offer, oradjusting attributes of an existing offer. In another example, the webserver 22 may include code for providing a webpage with interfaces bywhich merchants create a new merchant account, view data about amerchant account, or adjust attributes of a merchant account. Similarly,the web server 22 may include code for providing a webpage withinterfaces for specifying a publisher account, viewing a publisheraccount, or adjusting a publisher account. In some cases, theseinterfaces include buttons that when selected cause client-side scriptsto communicate with web-server 22. Other example interfaces include textboxes, radio buttons, check boxes, and the like for data entry. Browsersexecuting on user devices may submit entered data and commands to theweb server 22, which may advance the commands to the controller 26 forresponsive action by the affiliate-network system 12. Similarly, the webserver 22 may receive requests for resources from such user devices, forexample, to form the corresponding webpages, and the web server 22 mayadvance requests for responsive content to the controller 26 forretrieving and returning the responsive content.

The API server 24, in some cases, may be configured to supportprogrammatic interaction with the affiliate-network system 12 throughprograms (e.g., non-web-browser programs) executing on the publisherservers 18, the merchant system 16, or consumer user devices 20. The APIserver 24 may support a variety of commands to manipulate or retrievedata from the affiliate-network data store 28, examples of which aredescribed throughout this document. In some cases, the API server 24 maybe operative to receive a request for offers from a publisher server 18and advance that request to the controller 26 which retrieves responsiveoffers from the affiliate-network data store 28. The API server 24 mayreturn those offers to the publisher's server 18 from which the requestwas received. In some cases, the request specifies various criteria ofthe offers, such as geographic criteria, a category of offers, a type ofredemption, a merchant, a category of merchant, or other offerattributes, and the API server 24 instructs the controller 26 toretrieve responsive offers satisfying the criteria. Similar requests maybe received from the merchant system 16 or the user devices 20,depending upon the application. In some cases, the API server 24 isoperative to receive and initiate responses to publisher or merchantrequests for role-specific analytics, such as data for reports providedby the analytics module 34 described below. Other interfaces supportedby the API server 24 may include, in some embodiments, uploadfunctionality, by which merchants upload new offers programmatically,change offers programmatically, or upload transaction data describingin-store redemptions of offers. Similarly, in some cases, publishers mayupload information about user interactions with the offersprogrammatically, or consumer user devices 20 may upload informationabout consumers or consumer interactions with offers programmatically,provided that the consumer has opted in to the appropriate privacysettings allowing such upload.

In some embodiments, the controller 26 is operative to receive commandsand data from the web server 22 or the API server 24 and coordinateresponsive actions by the other components of the affiliate-networksystem 12. Examples of activities coordinated by the controller 26 aredescribed below with reference to FIGS. 2 through 6. In some cases, thecontroller 26 is operative to translate web requests or API requestsinto corresponding data transformations and database interactions tostore or retrieve implicated data.

In some embodiments, the affiliate-network data store 28 stores dataabout merchants, publishers, offers, and consumer interactions withoffers. The affiliate-network data store 28, in some cases, is arelational database, or other types of data stores may be used,including hierarchical key-value stores, program state, and memoryimages. In this embodiment, the affiliate-network data store 28 includesa merchant data store 36, a publisher data store 38, an offer data store40, and a tracking data store 42. In some cases, each of these datastores 36, 38, 40, and 42 may be separate databases or, in other cases,these data stores may be intermingled in a single database or other datastore. The affiliate-network data store 28 may be operative topersistently store data about merchants, publishers, offers, andconsumer interactions with those offers. In some cases, theaffiliate-network data store 28 is configured to receive queries, forexample, submitted in the form of structured query language fromcontroller 26 and respond with responsive data. Similarly, theaffiliate-network data store 28 may be responsive to commands fromcontroller 26 to store data or delete data, e.g., when creating newrecords or changing records.

In some embodiments, the merchant data store 36 is configured to storedata about merchants that use the affiliate-network system 12 todistribute offers and track interactions with those offers. In someimplementations, the merchant data store 36 stores a plurality ofmerchant records, each merchant record corresponding to a differentmerchant account with the affiliate-networking system, and in somecases, corresponding to a different merchant. In some cases, eachmerchant record includes the following data: a trade name of themerchant; a business-entity name of the merchant; a unique merchantidentifier by which the merchant record may be linked to other recordsin the affiliate-network data store 28; merchant-specific brandingcontent (such as images of the merchant's logo at various resolutions,merchant tag-lines, merchant website URLs, or URIs of such content) foruse in the merchant's offer content; analytics tags (examples ofanalytics tags include code or resources, like a tracking pixel, to beadded to offer content, like an offer page, corresponding to therespective merchant's analytics system (e.g., Omniture provided by AdobeSystems, Inc. of San Jose, Calif., or Google Analytics provided byGoogle Inc. of Mountain View Calif., among others) that cause the userdevice to provide information with the merchant's analytics system,thereby allowing the merchant to measure performance of the offercontent as if it was part of their own website or mobile application);geographic merchant locations (e.g., a plurality of site records, eachsite record corresponding to a brick-and-mortar site and having alocation—like a street addresses of the store, latitude and longitudecoordinates of the store, or coordinates of a polygon bounding thestore—along with store hours, point-of-sale capabilities—like barcodescanning, optical scanning, and NFC capabilities that may be used toexchange data with consumer user devices during an in-store couponredemption—and various merchant-defined categories) for selecting offersbased on location or store-specific attributes; merchant categories(e.g., sporting goods, financial services, retail clothing, and thelike) for selecting offers based on merchant specialty; supported couponcode formats (e.g., whether the merchant supports single-use couponcodes that are unique to a customer or customer session with a publisheror other coupon provider, or whether the merchant supports multi-usecoupon codes that are widely distributed to multiple users) fordetermining offer configuration options for a merchant; merchant contactinformation (e.g., a plurality of employee records, each record having aname, password, role, phone number, email address, and permissions tointeract with the affiliate-network system 12 on behalf of the merchant)to facilitate controlled distribution of offers by authorized employeesof the merchant; and pre-approved publishers (e.g., publisheridentifiers corresponding to records in the publisher data store 38 thathave been whitelisted or blacklisted by the merchant, or a category ofpublishers that have been whitelisted or blacklisted) to facilitateefforts by merchants to limit distribution of their offers to publishersthat are consistent with the merchant's brand.

In some embodiments, the publisher data store 38 is configured to storedata about publishers that interact with the affiliate-network system 12to distribute offers. The publisher data store 38 may include aplurality of publisher records, each publisher record corresponding toone publisher account, and in some cases, a different publisher. Eachpublisher record may include the following data: a publisher trade name;a publisher business-entity name; a publisher identifier that is uniqueto the publisher record in the affiliate-network system 12 and is usedto link the publisher record to other records within theaffiliate-network data store 28; a publisher category (e.g., nominalvalues in a taxonomy of publishers, such as those identifying sports orfashion-related publications); publisher-specific content and resources(e.g., images of the logo of the publisher at various resolutions,publisher-selected settings to configure the visual presentation ofoffers distributed by that publisher—such as settings defining apublisher's color scheme and indicating which colors are mapped to whichoffer presentation elements, like buttons, headers, and the like, apublisher's font selection, and various cascading style sheet settingsdefined by the publisher—as well as a publisher's contact informationfor consumers—like a web address of a help webpage or FAQ webpage hostedby the publisher, and various other links to other portions of thepublishers website, such as a homepage of the publisher, or URIs of suchpublisher content or resources) to configure offer presentation from theaffiliate-network system 12 in a manner that is consistent with thepublisher's brand; publisher analytics tags (e.g., like those describedabove with respect to merchants except tied to a publisher's analyticssystem); publisher metrics (e.g., audience size as measured by pageviews, unique page views, number of publisher mobile device applicationinstalls, or audience demographics, including geographic distribution ofthe audience, income of the audience, education level of the audience,interests of the audience, occupations of the audience, and variousother statistics characterizing the publisher's audience) to facilitateselection of publishers by merchants according to the publishersaudience; distribution channels of the publisher (e.g., publisherwebsites, mobile device native applications, set-top box applications,and various other programs for displaying and interacting with publishercontent on consumer user devices) to facilitate selections of publishersby distribution channel or selections of distribution channels bymerchants; publisher geolocation capabilities (e.g., values indicatingwhether the publisher is capable of obtaining a user geolocation from alocation sensor on a mobile phone, Internet Protocol addressgeolocation, or a user profile maintained with the publisher) tofacilitate selection of publishers by merchants according to theexpected reliability and existence of geolocation information; otherconsumer user device interfaces to which the publisher has access (e.g.,values indicating whether the publisher operates a native applicationconfigured to access a camera of the consumer user device, a microphoneof the consumer user device, a near-field communication interface of theconsumer user device, a Bluetooth™ user interface of the consumer userdevice, or other such wireless interfaces) to facilitate selection ofpublishers by merchants according to these capabilities; and publishercontact information (e.g. a plurality of employee records, each having aname, password, role, phone number, email address, permissions tointeract with the affiliate-network system 12, and the like of variousemployees of the publisher).

In some embodiments, the offer data store 40 is configured to store dataabout offers issued by merchants for distribution by publishers. Theoffer data store 40 may store a plurality of offer records, each offerrecord corresponding to a different offer by a merchant. In someembodiments, each offer record includes the following data: an offeridentifier unique within the affiliate-network system 12 and used tolink the offer record to other records in the affiliate-network datastore 28; a merchant identifier indicating the merchant issuing theoffer and linking to one of the merchant records in the merchant datastore 36; an offer title to be included as part of offer contentdisplayed on consumer user devices when displaying the offer; a startdate of the offer indicating the date or time upon which the offerbecomes valid for redemption; an expiration date indicating the date ortime upon which the offer ceases to be valid and can no longer beredeemed; a publication date indicating the date or time upon which theoffer is available for publishing by publishers; a publication finishdate indicating the date or time upon which the offer will cease to beavailable for publishing; an offer type (e.g., a nominal valueindicating whether the offer is a coupon, a sale, a rebate, an offer fordiscounted shipping, or the like) to facilitate filtering of offers byoffer type by publishers or consumers; an offer tracking type (e.g., aBoolean value indicating whether the offer is being tracked, or anominal value indicating a type of tracking); an offer monetization type(e.g., a Boolean value indicating whether the offer is being monetized(e.g., whether the merchant is compensating the operator of theaffiliate-network system 12 for distributing the offer, such as a flatfee, a percent commission, or a cost-per-click reward); a commissiontype (e.g., a nominal value indicating whether commissions to publishersare based on a per-interaction rate, a per-redemption rate, aper-impression rate, or the like); a commission rate (e.g., a percentageor dollar amount); an offer description (e.g., a prose description ofthe offer to be sent to consumer user devices 20 when displaying theoffer); offer rules (e.g., a condensed, consumer-friendly prosedescription of relatively significant terms and conditions, such asthose limiting the offer to particular brands or highlighting anexpiration date, for use when displaying the offer); offer terms andconditions (e.g., a relatively comprehensive prose description of termsand conditions provided by the merchant and defining the terms of theoffer, which may be presented in response to a user selection of aninterface in the offer content to request the terms and conditions); astore applicability type of the offer (e.g., a Boolean value indicatingwhether the offer is applicable across a store with no brand or categoryrestrictions, or a nominal value indicating the absence or presence ofvarious types of such restrictions); a domain, publisher, or publishercategory whitelist or blacklist of the offer to facilitate fine-grainedpublisher-by-publisher distribution of subsets of offers by merchants;offer user-interaction limits (e.g., key-value pairs listing a userinteraction type, such as printing, sharing in a social network, sendingto a text message, or combinations of such interactions, and a limit onthe number of permitted interactions for the offer, such as a limitednumber of times the offer may be printed, shared, sent to a textmessage, sent to a card-linked offer account, sent to an email account,saved to a clipboard memory of the consumer user device, or sent to anelectronic wallet, or combinations thereof, including the aggregate ofall interactions) to facilitate efforts by merchants to control thenumber of redemptions of offers; an offer redemption type (e.g., a listof nominal values indicating the channels through which the offer isredeemable, such as on mobile devices, by printing, by printing from amobile device, across all channels, or a listing of particular mobiledevice applications, accepted card-linked offer account providers,electronic wallet providers, or the like that constitute a whitelist orblacklist of channels through which the offer is redeemable or notredeemable) to facilitate efforts by merchants to establish exclusiverelationships with providers of such accounts and favor particular typesof redemption channels through which offers are believed by merchants tobe more effective; an in-store redemption indicator (e.g., a Booleanvalue indicating whether the offer is valid for in-store redemption bypresentation of, for example, a coupon code or offer barcode, by aconsumer to a clerk at a point-of-sale terminal) to again facilitateefforts by merchants to control redemption channels to those believed tobe effective for the particular offer; a percentage discount of theoffer (e.g., 20% off the base price of some good or service) tofacilitate offer curation by publishers and consumers according to theamount of the discount and for display on the consumer user device whendisplaying the offer; a percentage-up-to value indicating whether someapplicable discounts supported by the offer are less than the percentageoff value; a minimum purchase value (e.g., a minimum purchase amount indollars or number of goods or services required to receive thepercentage off discount of the offer) for offer filtering and display; adollar amount off from the offer (e.g., five dollars off the price ofsome good or service) for offer filtering and display; a dollar-up-toamount indicating whether some applicable discounts from the offer areless than the dollar amount off; a minimum-dollar-purchase amountindicating the amount required to be purchased to activate the offer'sdollar amount off discount; a Boolean value indicating whether the offerincludes a free gift; a prose description of a free gift item; a freeshipping Boolean value indicating whether the offer is associated withfree shipping of goods; a free-shipping minimum-purchase amountindicating the minimum amount that the consumer must purchase to receivefree shipping; a free-gift minimum purchase indicating the minimumpurchase required to receive the free gift; a buy-X-get-Y-free key-valuepair indicating how many free items are offered for a number of itemspurchased (e.g., buy one get one free); a by-X-get-Y-free minimumpurchase indicating the minimum amount to be purchased to activate theoffer for buy-X-get-Y-free key-value pairs; and a category of the offer(e.g., a single-level taxonomy of offers, or a hierarchical taxonomy ofoffers, such as retail/sporting goods/golf equipment) to facilitateoffer filtering and selection by consumers and publishers.

In some embodiments, the tracking data store 42 is configured to storedata about interactions with offers, such interactions includingin-store redemptions, on-line redemptions, interactions requesting thatoffer be sent to another consumer user device, or another consumeraccount (e.g., a card-linked offer account, an electronic walletaccount, an email account, a social networking account, or the like). Insome cases, the tracking data store 42 includes a plurality ofoffer-tracking records, each offer-tracking record corresponding to adifferent instance of interaction with an offer (e.g., a given consumer,requesting a printable view of a given offer and that consumerpresenting the printout at a point-of-sale to redeem the offer wouldconstitute two records). In some embodiments, each offer-tracking recordincludes the following data: an interaction identifier unique within theaffiliate-network system 12 and by which offer interactions are linkedwith other records within the affiliate-network system 12; an identifierof an offer to which the interaction relates (e.g., an identifier of oneof the offer records in the offer data store 40); a publisher identifierindicating the publisher to be credited with the interaction (e.g., anidentifier of one of the publisher records in the publisher data store38 identifying a publisher that distributed the offer to a consumer userdevice 20 through which the interaction occurred); related interactions(e.g., identifiers of earlier interactions potentially causally relatedto the interaction record, such as a print interaction that lead to anin-store redemption interaction, or a social-network sharing interactionthat lead to an on-line redemption interaction by the recipient); aconsumer user device identifier that identifies the consumer user device20 upon which, or through which, the interaction occurred (e.g., amedium access control (MAC) address of the consumer user device, anadvertiser identifier associated with the device, or other deviceidentifier); an identifier of a consumer associated with the consumeruser device upon which, or through which, the interaction occurred(e.g., an identifier of a user profile account having information aboutthe user that interacted with the offer, such as name, address, offerpreferences, and the like); an identifier of a session during which theinteraction occurred; an identifier of an interaction-specific offercode (e.g., a single-use code dynamically generated when presenting theoffer and that when presented for redemption, either in-store oron-line, identifies (e.g., uniquely) the corresponding interactionrecord); a publisher-specific offer code (e.g., an offer code for agiven publisher that facilitated the interaction and that uniquelyidentifies the publisher when the offer is presented for redemption); aninteraction type (e.g., a nominal value indicating on-line redemption,in-store redemption with a coupon code, in-store redemption by mobiledevice screen, in-store redemption by mobile device display, in-storeredemption by mobile device wireless interaction with a point-of-saleterminal, in-store redemption with a printed copy of the offer, on-lineor in-store redemption with a card-linked offer account, on-line orin-store redemption with an electronic wallet account, or the like); aninteraction location indicating, to the extent known, a geographiclocation at which the interaction occurred (e.g., an identifier of amerchant's physical store, a geocoded IP address of a consumer userdevice used in the interaction, a location sensed by a location sensorin the consumer user device, or the like); a time of the interaction(e.g., a timestamp); a merchant associated with the interaction (e.g., amerchant through which the offer was redeemed, which in some cases maybe different from the merchant that issued the offer, for example, foroffers issued by brands redeemable at various retail stores); aninventory of goods or services purchased during the interaction (e.g., aplurality of transaction records listing items purchased andcorresponding purchase amounts for calculating an aggregate value forthe transaction upon which publishers are compensated in some cases); atransaction currency; and a consumer-user-device type of the device uponwhich the interaction occurred or was facilitated (e.g., an indicator ofwhether the consumer user device is a cell phone, tablet, personalcomputer, laptop, set-top box, in-dash automotive computer, a wearablecomputing device, or identifying a maker or software provider for thedevice).

Such fine-grained transaction data is expected to facilitate relativelyreliable compensation of publishers by merchants, aligning the interestsof the two groups, and relatively high-resolution analytics of consumeractivity for improving the design of offers and publisher content. Forinstance, some merchants may compensate publishers for offers beingprinted or sent to another device even when the ultimate redemption ofthe offer in-store is not recorded by an interaction record. Often, whenusing traditional affiliate-network systems, in-store sales clerks willscan an offer barcode from a printout at their register, rather thanscanning the barcode presented by the consumer, because doing so is asimpler and repetitive action, but in doing so, the publisher ispotentially denied credit they might otherwise obtain from scanning apublisher-specific or single-use bar code on the printout our consumeruser device display. Tracking printing and various transfers of offersbetween devices and accounts offers merchants a supplemental metric fordetermining publisher compensation and encouraging desirable publisherefforts to distribute offers.

Thus, the affiliate-network data store 28 may store values related tothe provision and tracking of offers on-line and in stores. Theaffiliate-network data store 28 may be operative to filter, search,join, sort, augment, create, delete, modify, and search theabove-mentioned records in a variety of permutations of subsets of therecords. It should be noted that not all embodiments include all of thefields discussed above with reference to the affiliate-network datastore 28 and that some embodiments store additional fields or use theabove-mentioned fields for different purposes than are described, whichis not to suggest that any other feature described herein may not alsobe omitted or used in a different fashion than is described.

In some embodiments, the content-negotiation module 30 is configured todynamically format offer content according to the manner in which offerswill be displayed to a consumer. In some embodiments, each offer isassociated with an offer-specific URI (e.g., a uniform resource name(URN) or locater (URL)) that corresponds to multiple presentationformats of the offer appropriate for different devices or accounts. (Andin some cases, the URI is both offer specific and publisher specific, asexplained below.) The content-negotiation module 30 may be configured toform (e.g., select among or dynamically generate) these presentationformats based on attributes of the consumer user device 20 upon whichthe offer will be displayed or (i.e., and/or) attributes of an accountthrough which the offer will be conveyed to a user (e.g., an emailaccount, a social networking account, a card-linked offer account, or anelectronic wallet account).

To this end, the content-negotiation station module 30 may be configuredto receive data about the type of presentation (e.g., device attributesor account attributes) with a variety of different techniques. In somecases, a request from a consumer user device 20 to the affiliate-networksystem 12 for offer content corresponding to a URI includes user agentinformation about the consumer user device 20, such as a user agentstring in a header of a request specified by a transport protocol (e.g.,HTTP or SPDY). In some cases, the user agent information may be includedwith a get request under the transport protocol for resources at theURI. User agent information may include an identifier of a web browser,an operating system, a listing of accepted media types, supportedcharacter sets, encodings, languages, and the like. In some cases, therequest for content at the offer URI includes information about themanner in which the offer will be displayed, for example, a screen sizeexpressed in resolution or absolute geometric dimensions, a window sizeexpressed in pixels or geometric dimensions, color capabilities,three-dimensional capabilities, and the like. In some cases, the requestindicates whether the offer will be displayed on a printout from aprinter, or whether the offer will be displayed in a particular type ofaccount, such as those listed above.

In some cases, the request is not a sufficiently-specified descriptionof how the offer will be displayed, and the content-negotiation module30 may send instructions to the requesting consumer user device 20 tofurther identify such attributes, such as JavaScript™ that when executedreturns a window size, a screen resolution, and i-frame size, a div-boxsize, a document-object-model (DOM) element size, or the like, withinwhich the responsive offer content will be displayed. The code, whenexecuted in a web-browser of a consumer user device 20, may return thecorresponding parameters to the content negotiation module 30. In somecases, the request is from a native application executing on a consumeruser device 20, and the request is received via the API server 24. AnAPI of the affiliate-network system 12 may specify that requests includethe above-mentioned information about the consumer user device 20 oraccount, or embodiments may send a default format of offer content whensuch information is unavailable.

In some embodiments, the content-negotiation module 30 is configured toretrieve the appropriate offer content for the URI (e.g., offerresources, like prose descriptions and images, and instructions fordisplaying the resources and, in some cases, for providingoffer-selection interfaces for a given offer) based on the dataindicating how the offer will be displayed. For example, thecontent-negotiation module 30 may receive data indicating that the offerwill be displayed on a mobile phone, tablet, laptop, or desktop computerin a web browser, email account, text message, social networkingaccount, card-linked offer account, electronic wallet account, or thelike. In response, the module 30 may form (e.g., select or generate) anoffer presentation template corresponding to one of these types ofpresentation. Thus, some embodiments of the content-negotiation module30 may store in memory a plurality of different offer presentationtemplates, each template corresponding to a different type of consumeruser device, presentation environment on a consumer user device, oraccount through which the offer will be presented to a user. Or in somecases, some or all of the offer templates are dynamically generatedaccording to the type of presentation, for example, dynamically scalingdimensions, image resolutions, and font sizes with the size of thedisplay of the consumer user device 20 or size of a window or DOMelement in which the offer content will be shown.

An offer template, in some cases, specifies text to be included in offercontent, for example, specifying the inclusion of more expansive prosedescriptions of offers in templates for larger display screens oraccounts in which longer bodies of text are appropriate (like in email,as opposed to text messages). In some cases, shorter and longer versionof offer descriptions are maintained in the offer records for thispurpose. Similarly, offer templates may specify larger fonts,higher-resolution images, and more images, in templates for largerdisplay screens or for accounts configured to accommodate richercontent. Thus, the offer templates may include instructions to retrieveand display various offer-related resources, such as a merchant logo, anoffer-specific image, a prose description of the offer, and adescription of various terms and conditions of the offer. In some cases,various versions of the offer content are maintained in the offer datastore 40, such as lower and higher resolution versions of images, andmore concise and less concise versions of text, and the offer templatesmay specify these different versions depending upon the type ofpresentation to the consumer.

Offer template selection may also depend upon the potential use of aconsumer user device 20 for in-store redemptions (e.g., templates maydiffer for mobile phones and desktop computers to account for thepotential presentation of the mobile device in-store). In someimplementation, templates for printing offers (e.g., those that provideprintable views of offers in black-and-white and are sized for A4 paper)may include a barcode image (or QR code, or the like) that can bescanned at a point-of-sale terminal for redeeming an offer. Templatesfor use on mobile user devices may include such images as well (e.g., byspecifying that when the template is populated for a given offer, abarcode image for that offer is generated or retrieved and added tooffer content formed based on the template). Images foroptically-machine-readable codes, like barcodes and QR codes, may beincluded in (e.g., linked to with a URI) the above-mentioned offerrecords. Or some embodiments may generate publisher-specific,user-specific, or session-specific optically-machine-readable codes thatuniquely identify one of these items. The code may be associated with apublisher record, a user profile, or an interaction record, depending onthe application, and after the code is scanned at a point-of-saleterminal, the respective item (e.g., publisher record, user profile, orinteraction record) may be associated with the transaction at thepoint-of-sale terminal to track publisher, user, and offer metrics.

In some cases, the offer templates include (e.g., specify, in part, howto form) interfaces by which a user further interacts with offers.Examples of such interfaces include on-screen buttons that, whenselected (e.g., by touching or clicking), launch a client-side script orroutine that issues a request from the consumer user device to theaffiliate-network system 12 for a different presentation of the offer,such as a printable view. With a similar process, other includedinterfaces (e.g., buttons, voice commands, or gestures) may indicatethat the offer should be sent to another consumer user device 20 oraccount, such as a button to launch an interface for entering a phonenumber to which offer content is texted or an email account to which anemail version of offer content is sent. In some cases, the set ofinterfaces are different for the different templates.

In some cases, the offer templates include publisher-specific attributesof offer content that are formed (e.g., selected or generated) based onthe identity of the publisher that advanced the URI to a consumer userdevice 20 (which then requests corresponding offer content from theaffiliate-network system 12). To this end, in some embodiments, thecontent-negotiation module 30 may parse from the request for offercontent an identifier of a publisher, and the module 30 may retrieveinformation for populating the template based on publisher-specificcontent, such as images and other attributes like colors, fonts, links,and text. For example, offer content may include one or more on-screenbuttons, and an offer template may specify a publisher-button-colorfield for determining the button color. In response, when populatingthis template for a URI advanced by a given publisher, thecontent-negotiation module 30 may retrieve from the publisher data store38 that publisher's selection of a color of the button and form offercontent in accordance with the selection. Similar fields may specifyother aspects of offer content. Thus, in some embodiments, differentpublishers may direct consumers to the same offer with different colors,publisher logos, publisher's terms of use, links to other publishercontent, links to publisher help webpages, and the like.

In short, the content-negotiation module 30 customizes offer contentbased on context. In some embodiments, the visual depiction of an offermay depend on the attributes of the consumer user device 20 upon whichthe offer will be displayed, the type of account through which the offeris presented, and the publisher from which the consumer user device 20received the URI of the offer. The content-negotiation module 30 maypopulate the templates based on responsive resources and sendinstructions to the consumer user device 20 to display the offercontent.

In some embodiments, the affiliate-network system 12 includes adynamic-terms offer controller 32 that dynamically adjusts the terms ofoffers (e.g., types of redemption, expiration date, start date, percentdiscount, and the like) based on feedback from the tracking data store42, which may indicate both an amount of on-line redemption activity andoff-line (such as in-store) redemption activity. Some embodiments of thedynamic-terms offer controller 32 perform a process described below withreference to FIG. 11. The affiliate-network system 12, as noted above,tracks offer interactions across multiple channels. A benefit of thisapproach is that offers can be dynamically controlled relativelyreliability based on relatively comprehensive accounting of offer usageor likely usage. (Though, not all embodiments necessarily provide thesebenefits.) For instance, a merchant may specify that the percentdiscount of an offer is to decrease by some amount (or the offer is toexpire) automatically in response to the aggregate of on-line andoff-line interactions exceeding a threshold rate or amount, therebyconstraining offers that have spread more widely than anticipated orpotentially specify a greater discount than the merchant intended tooffer due to a data entry error. In some cases, these thresholds are setautomatically, for instance at five standard deviations of an aggregaterate (e.g., a daily average) of accumulation of offer interactionrecords for offers for a given merchant, and alerts are issued to themerchant in response to the threshold being exceeded so that themerchant can manually intervene and terminate or adjust an offer ifneeded.

In some embodiments, the affiliate-network system 12 further includesthe analytics module 34, which may be configured to query data from thetracking data store 42 and present role-specific reports to publishers,merchants, and administrators of the affiliate-network system 12.Examples of reports are described below with reference to FIGS. 9 and10. The analytics module 34 may be operative to receive a request forsuch a report specifying various criteria, such as a merchant account ora publisher account, query the tracking data store 42 for the responsivedata, and generate visual depictions of the data, such as thosedescribed below. Reports that account for both on-line and off-lineinteractions with offers are expected to simplify the process ofmonitoring and analyzing offers that are redeemable through multiplechannels, an undertaking which can be relatively arduous withtraditional affiliate-network systems, particularly for merchantsissuing hundreds of new offers each day. (Though, again, not allembodiments necessarily provide this benefit.)

Some embodiments of the affiliate-network system 12 implement techniquesto protect user privacy, for example, anonymizing identifiers ofconsumer user devices 20 by hashing information from the consumer userdevices 20, reducing the granularity of attributes recorded inassociation with user interactions (like rounding less significantdigits of latitude and longitude coordinates), and providingprivacy-controls by which consumers or publishers can implement userprivacy-preferences.

In summary, the affiliate-network system 12, in some embodiments, isoperative to coordinate activities relating to offers by web-scalenumbers of consumer user devices 20, merchant systems 16, and publishers18, which may implicate potentially hundreds of thousands or millions ofoffers, some of which may be dynamically adjusted with terms that changeover time, some of which may have visual depictions that are dynamicallyadjusted, and some of which may have single-use offer tracking codescorresponding to an individual consumer interactions with offers. Toaccommodate operations at these scales, in some cases, theaffiliate-network system 12 may include a relatively large number ofgeographically distributed networked computing devices and employvarious techniques to speed operation, such as use of elastic scaling ofthe system 12 and use of content-delivery networks.

FIGS. 2 through 6 are a flowchart showing an embodiment of a process 44for distributing offers both on-line and off-line (e.g., in-store orthrough multiple devices or accounts). Some embodiments of process 44are performed with the affiliate-network system 12 described above,though it should be noted that embodiments are not limited to theparticular features of that system 12. The flow charts of FIGS. 2through 6 are arranged in four columns, each column corresponding to therole of a different entity and associated computing hardware performingparts of the process 44. In other embodiments, the various roles of thedifferent entities may be arranged differently, for example, themerchant may operate the affiliate-network system, the affiliate-networksystem and the publisher server may be operated by the same entity, orthe merchant system, affiliate-network systems, and the publisher servermay all be part of the same system operated by the same entity,depending upon the arrangement. Embodiments of the process 44 may beeffectuated by one or more data processing apparatuses, examples ofwhich are described below with reference to FIG. 12, executinginstructions stored on a tangible, non-transitory, machine-readablemedium, such as various forms of computer memory like, dynamic randomaccess memory and persistent storage in the form of hard drives oroptical media.

The process 44, in some embodiments, describes the life-cycle of anexemplary offer, beginning with the creation of accounts of merchantsand publishers, followed by the offer being defined by the merchant, anaffiliate-network system distributing the offer to the publishers, thepublisher making a consumer aware of the offer, the consumer redeemingthe offer either in-store or on-line, and arrangements being made forcompensation of the publisher by the merchant based on tracking of theoffer redemption or other interactions with the offer. Like the otherembodiments described herein, various portions of the process 44 aredirected to different problems with existing affiliate-network systems,such as those described above, and as such, subsets of the process 44are expected to be independently useful, which is not to suggest thatany other features described herein cannot also be omitted in someembodiments.

In some embodiments, the process 44 begins with the merchant systemsending merchant parameters to the affiliate-network system, and theaffiliate-network system adding those merchant parameters to a merchantdata store, as indicated by blocks 46 and 48 in FIG. 2. The merchantparameters may include some or all of the fields in the merchant recordsdescribed above with reference to the merchant data store 36 of FIG. 1.In some cases, the merchant parameters are provided through a websiteinterface hosted by the affiliate-network system. This website mayinclude interfaces by which a merchant can populate a merchant record(or an administrator of the affiliate-network system may enter thoseparameters on behalf of the merchant). The merchant system may includean employee's user device by which the employee provides the merchantparameters via email or a via a web browser, in some cases. In some usecases, the merchant parameters define a merchant account with associatedmerchant employee accounts with usernames and passwords for grantingvarious levels of access to merchant employees based on the amount ofauthority granted by the merchant to those employees. The merchantparameters may be stored in one of the above-mentioned merchant records,and a unique merchant identifier may be created for the merchant recordto distinguish the merchant record from those of other merchants.

Next, in some embodiments, the merchant system sends offer parametersthat specify an offer the merchant wishes to have distributed, and theaffiliate-network system adds the offer parameters to an offer datastore, as indicated by blocks 50 and 52. In some cases, the offerparameters include some or all of the fields of an offer recorddescribed above with reference to the offer data store 40. Sending theoffer parameters may include an employee of the merchant logging into amerchant account in the affiliate-network system with a username andpassword that indicate the employee is authorized to create an offer onbehalf of the merchant. The affiliate-network system may host a websiteinterface by which the employee of the merchant enters the offerparameters, or the employee the merchant may provide those parametersvia email or phone call or other form to an administrator of theaffiliate-network system who then enters the offer parameters. In somecases, the affiliate-network system provides an API by which a merchantcan programmatically submit a command to add an offer to the offer datastore along with data specifying the offer parameters in a formatspecified by the API. The offer parameters may be stored in one of theabove-mentioned offer records, and an arbitrary but unique offeridentifier may be created for the offer record.

In some cases, each offer record includes values indicating the state ofthe offer in an offer approval work-flow. For example, a value in therecord may indicate that the offer has been created, that the offer hasbeen sent to an employee of the merchant for approval, or that the offerhas been approved by an employee of the merchant with authority toapprove offers. In some cases, different roles defined by merchantrecords may specify which employees have authority to create offers orapprove offers. Interfaces to solicit changes in state within suchwork-flows may be hosted by the affiliate-network system, such as inweb-based interface by which an employee can approve an offer or rejectan entered offer. Such controls are helpful for merchants that manage arelatively large number of offers, any one of which could potentially berelatively expensive to the merchant were a mistake made in defining anoffer, for example, by making an offer that is more generous than themerchant intended. Not all embodiments, however, include these features,which is not to suggest that any other feature cannot also be omitted.

The process 44, in some embodiments, includes a publisher server (or apublisher employee or a publisher employee's user device) sendingpublisher content and parameters to the affiliate-network system todefine a new publisher account, and the affiliate-network system addingthe publisher to a publisher data store, as indicated by blocks 54 and56. In some cases, the publisher parameters and content may include someor all of the contents of the publisher records described above withreference to the publisher data store 38 of FIG. 1. In some cases, thepublisher parameters are provided through a website hosted by theaffiliate-network system, the website presenting interfaces (e.g., textbox inputs, check boxes, radio buttons, file-uploaders for images) bywhich a publisher can populate a publisher record and upload publishercontent. Or publishers may send this information to an administrator ofthe affiliate-network system who then creates the publisher record inthe publisher data store. As noted above, in some embodiments, publisherrecords include data for customizing the presentation of offersaccording to the identity of the publisher such that when one publishersends a consumer a URI of a given offer, the offer appears differentlyon the consumer's user device relative to how that offer would appearhad a different publisher sent the same consumer the same offer. Asnoted, examples of such customization include button color, logos, linksto other publisher content, and the like. In some cases, the URIs foroffers sent to a given publisher include the name of the publisher, suchthat the appropriate publisher-specified visual attributes of offers canbe retrieved and applied when a consumer user device requests offercontent. In some cases, the portion of the URI identifying the publisheris provided by the publisher and is stored in a publisher record.Customizing the URI and visual aspects of offers content by publisher isexpected to make the affiliate-network system more desirable topublishers who may otherwise be concerned with distinguishing theirbrand from that of other publishers, while still providing a single,centralized system through which offer content is retrieved and throughwhich consumers interact with offers, such that both on-line andoff-line interactions with offers can be tracked. (Though not allembodiments necessarily provide these benefits.)

It should be noted that process 44, like the other processes describedherein, is not limited to the sequence illustrated. For example, in somecases, publishers may be added to the publisher data store beforemerchants are added to the merchant data store, and in some cases,multiple merchants, multiple offers, and multiple publishers may beadded at various points during the process 44, and multiple instances ofportions of process 44 may be performed concurrently (e.g., thousands ofoffers may be provided to millions of consumers at various times, andpublishers, merchants and offers may be added at various times). Thesteps 46-56 are merely exemplary steps illustrating the accumulation ofdata in the affiliate-network system for distributing offers.

The process 44, in some embodiments, includes the publisher serverrequesting offers for publication, and receiving this request through anAPI at the affiliate-network system, as illustrated by blocks 58 and 60.In some cases, the publisher server may periodically submit requests foroffers (for instance, as a batch process run hourly or daily), or thepublisher server may request offers for publication in real-time (forexample, in response to a request from a consumer user device to thepublisher server for offers). In some cases, the request may specifycriteria by which offers are to be selected. For example, the publishermay request offers specific to a geographic area, a category of goods orservices, a particular redemption channel (e.g., on-line or in-store), acategory of merchants, a particular merchant, or a particular timeperiod for expiration or publication (e.g., offers published since thelast time offers were requested by that publisher).

In response to the request, the affiliate-network system may retrieveresponsive offers (e.g., from the offer data store 40 of FIG. 1) andsend those offers to the publisher server, which may receive the offersfor publication, as indicated by blocks 62 and 64. In some cases, therequest for offers identifies the publisher, for example, with apublisher username and password provided in the API request, and theresponsive offers are filtered according to merchant selections eitherblacklisting or whitelisting publishers, as some merchants do not wishtheir offers to be associated with publishers inconsistent with themerchant's brand. In some cases, a plurality of responsive offerssatisfying both the publisher's criteria and merchants' constraints aresent. Offers may be sent, for example, in a serialized data format, suchas JSON or XML, to the publisher server according to a format for offersdefined by the API. In some cases, sending an offer includes sendingsome or all of an offer record stored in the offer data store 40.

Sending offers may include creating a publisher-specific URI for eachoffer (e.g., a URI that resolves to an Internet Protocol (IP) address ofthe affiliate-network system and includes the name of a publisher andthe unique offer identifier), such that when the publisher sends thatURI to a consumer user device, the consumer user device retrievespublisher-specific offer-content from the affiliate-network system, andthe name of the publisher in the URI gives the consumer confidence thatthey are viewing content “from” a publisher with which they arefamiliar.

The publisher server may store the received offers in a database of thepublisher, such that the publisher can later query the database foroffers responsive to requests from consumer user devices. Code executingon the publisher server may parse the API response and update apublisher database with records for the offers in accordance with apublisher's data model for offers. Or for real-time presentation via thepublisher, the publisher server may immediately send a consumer userdevice instructions to display the offers, along with information bywhich a visual presentation is constructed. The offers received by thepublisher, in some embodiments, are not accompanied by scripts, markupdata, and styling data for presenting a visually pleasing offerpresentation. Rather, publisher servers use the data provided via theAPI to construct such presentations on consumer user devices accordingto the particular website or application of the publisher. (Though someembodiments may also provide such scripts, markup data, and styling datawith the offers sent to the publisher.)

In some cases, the publisher processes the received offers prior toreceiving a request for offers from consumer user devices or prior toresponding to such requests. For instance, some publishers may indexoffers for faster offer retrieval according to various indices (e.g.,like keywords, redemption channel, geographic area, and the like). Somepublishers may associate offers with accumulated consumer feedback,e.g., upvotes or downvotes for offers or ratings of offers by consumers,and rank offers based on such feedback or index offers according to keywords in commentary. Offers may be ranked according to a variety ofgeographic, user-specific, or offer-specific criteria, including anexpected return to the publisher for a given ranking of the offer basedon historical redemption rates for a given offer and for offers andconsumers having various criteria similar to those at issue when rankingoccurs.

As illustrated, the process 44 continues in FIG. 3. Some embodimentsinclude receiving, at the publisher server, a request for publishedoffers from a consumer user device, as indicated by blocks 66 and 68. Asnoted above, the consumer user device may be any of a variety ofdifferent types of computing devices, including mobile phones, tabletcomputers, laptop computers, desktop computers, set-top computers,in-dash automotive computers, gaming consoles, wearable computingdevices (such as smart watches or head-mounted displays), public kiosks,and the like. The request for published offers may be initiated by aconsumer interacting with a web browser or native application executingon the consumer user device, for example, by a user navigating to apublisher's webpage and interacting with that webpage to request offerssatisfying certain criteria. Or the request may come from a userinteracting with a native application for displaying offers, such as abarcode scanning application on a mobile device, or an application fordisplaying and discovering offers on a mobile device. In some cases, therequest for offers is initiated by a background process executing on themobile device, for example, a lock-screen-application on a cell phonethat displays offers to users automatically, an application on a mobiledevice for alerting consumers to offers based on the current geographiclocation of the user being proximate to a geolocation (e.g., within or athreshold distance) at which an offer is redeemable, or asocial-networking application through which the user receives alerts foroffers identified for the user by their friends.

In response to the request, the publisher server may identify responsiveoffers and send to the consumer user device a URI of the published offer(e.g., a publisher-and-offer-specific URI), as indicated by blocks 70and 72. In some cases, a plurality of offers are determined to beresponsive to the request, and a plurality of correspondingpublisher-and-offer-specific URI's are sent to the consumer user device,in some cases along with instructions to display information about theoffers to the consumer. In some embodiments, the information sent fromthe publisher to the consumer user device includes most or allinformation needed to construct an initial display of each offer, andthat initial display includes a link to the URI sent with the offer tothe publisher, such that when the user selects that link, additionalinformation about the offer is retrieved according to the URI.

In other cases, the publisher sends instructions to the consumer userdevice to retrieve information identified by the URIs without furtherinteraction by the user (or such instructions may be present within anative application executing on the consumer user device). For example,the publisher server may send a webpage with a plurality of otherwiseempty offer containers, each referencing a URI, and the consumer userdevice may automatically request content to populate each of thosecontainers (e.g., div-boxes, i-frames, or other DOM elements) withcontent identified by the respective URIs. As noted above, the URIs mayresolve to the affiliate-network system (e.g., on a different domainfrom the publisher) and, in some cases, include an identifier of thepublisher.

The consumer user device, in some embodiments, request offer contentidentified by each URI from the affiliate-network system, as indicatedby blocks 74 and 76. Requesting this content from the affiliate-networksystem rather than the publisher server provides a number of benefits,including more comprehensive tracking of consumer interactions withoffers than is generally available in traditional affiliate-networkingsystems, which often host the offer content, in its entirety, on thepublisher server. For example, embodiments of the affiliate-networksystem may centrally track interactions selecting the option to print anoffer, send an offer as a text message to a phone number, share theoffer in a social network, or send the offer to some other account, suchas an electronic wallet or card-linked offer account. In contrast,systems that rely on self-reporting by publishers can be difficult toadminister and properly audit. (Though not all embodiments necessarilyprovide these benefits, as some embodiments address other, independentproblems with existing systems.)

In some embodiments, the request for offer content itself constitutesone type of interaction tracked in one of the above-mentionedinteraction records in the tracking data store 42 of FIG. 1. In somecases, publishers may be compensated for merely presenting offers,regardless of whether the consumer interacts further with the offer, forexample, by redeeming the offer. Thus, some embodiments include a stepof recording the request in a tracking data store, as indicated by block78. Recording the request may include populating some or all of theabove-mention fields in an interaction record described above based onthe request. To credit the publisher, the publisher's identity may beparsed from the request for offer content at the URI from the consumeruser device, or a publisher's script or native application on theconsumer user device may identify the publisher, e.g., with an APIrequest including the publisher's identity.

In some embodiments, receiving the request for offer content at theaffiliate-network system initiates an offer-presentation configurationprocess 80 that is a subroutine of the process 44 (which is not tosuggest that other portions of the process may not also constituteindependently useful subroutines). The offer-presentation configurationprocess 80, in some implementations, customizes the visual presentationof offers based on one or more of the following: the publisher thatidentified the offer to the consumer; or attributes of the consumer userdevice (including a printer) or account in which the offer will beviewed. These activities may be performed by the above-describedcontent-negotiation module 30. In some cases, the process 80 includesdetermining a version of offer content to send based on consumer userdevice attributes and determining and sending a publisher-specificpresentation of the offer content, as indicated by blocks 81 and 82.Examples of dynamically customized offer presentations are describedbelow with reference to FIGS. 7 and 8. To simplify offer management andpresentation for publishers, the same URI may yield different visualpresentations of the offer appropriate to those devices or accounts.

The consumer user device may receive and display the customized offercontent, as indicated by block 84. The offer content may be displayed ina web browser or a special-purpose native application, depending uponthe use case, and some embodiments of the affiliate-network systemprovide offer content for both types of use cases. In some embodiments,the offer content specifies user interfaces for further interacting withthe offer content, such as buttons, gestures, text inputs, voice inputs,or the like, for the consumer to express an intent to take furtheraction with respect to a specific offer. The interfaces may beconfigured such that user selections of a given interface results in theuser selection being reported to the affiliate-network system along withdata identifying the publisher (e.g., with the request itself or with asession identifier associated with the publisher). Examples of suchfurther actions include printing the offer, texting the offer to a cellphone number, emailing the offer to an email address, sending the offerto a card-linked offer account, or sending the offer to an electronicwallet. Other examples include taking action to facilitate on-lineredemption of the offer, such as revealing an otherwise concealed orwithheld coupon code or loading such a coupon code to a clipboard memoryof the consumer user device, for instance, with a native mobileapplication or a flash object executing within a web browser, the flashobject having heightened security privileges relative to the defaultprivileges afforded scripts executing within a web browser for accessingclipboard memory.

The process 44 further includes receiving user interaction with theoffer content at the consumer user device, as indicated by block 86. Insome cases, the consumer user device executes an event handler thatlaunches various routines depending upon a user's input, and thoseroutines may initiate the requested actions, such as requesting theaffiliate-network system to send the offer to some other device oraccount. Depending on the type of the user's interaction, the process 44takes different paths, as indicated by decision block 88 identifyingalternate branches depending on whether on-line or off-line redemptionwas selected. In this embodiment, if on-line redemption is selected, theprocess 44 proceeds to the node labeled “B,” which is continued in FIG.4, or if a form of off-line redemption is selected, the process 44proceeds to node “C,” which is continued in FIG. 5.

FIG. 4 shows an example of what happens following a consumer selectionof on-line redemption. In this embodiment, the affiliate-network systemreceives, from the consumer user device, in response to the user'sselection, a request for on-line redemption information, as indicated byblock 98. The request may be a request for a coupon code, such as a codethat is withheld from the consumer user device until requested or isconcealed on the consumer user device until requested, or the requestmay be a request to navigate to the merchant's website. To preventpublishers from claiming credit for a consumer merely requesting contentfrom the publisher's domain, some embodiments require that a consumertake an additional affirmative step of selecting an offer before thepublisher is credited with the user's interaction, as some publishershave been known to send code to the consumer user device that indicatesin memory that the consumer selected the offer without the consumeractually having done so, thereby potentially causing the publisher to beovercompensated by the merchant. (Though it should be noted that not allembodiments must include this policy.)

Next, in this embodiment, the request is recorded (e.g., documented) inthe tracking data store and memory of the user device, as indicated byblock 100. Recording the request in the tracking data store may includecreating one of the above-mentioned interaction records described abovewith reference to FIG. 1. Recording the request in memory of the userdevice may include sending and executing code on the consumer userdevice (e.g. JavaScript™ code) that loads a value into persistentclient-side storage remotely accessible to the domain of theaffiliate-network system (e.g., in a cookie or in LocalStorage). Or someembodiments only use one of client-side and server-side storage, whichis not to suggest that any other feature cannot also be omitted. Therecorded request may include an identifier of the publisher, such thatthe publisher can be compensated for the consumer's interaction or forlater interactions, like consumer redemption of the offer or consumerssharing the offer.

In some embodiments, the process 44 include both sending instructions torequest content from the merchant to the consumer user device andreceiving those instructions at the consumer user device, as indicatedby blocks 102 and 104. In some cases, the instructions are a redirectcommand sent to the consumer user device along with code that instructsthe consumer user device to store the request in a cookie orLocalStorage. The redirect command may cause the consumer user device tonavigate to a merchant's website and, in some cases, to a specificwebpage of the merchant associated with the offer (e.g., a product page)in an offer record in the above-mentioned offer data store 40.

The consumer user device, in response, may request content from themerchant, as indicated by block 106, and the merchant may receive thisrequest and send the requested content back to the consumer user device,as indicated by blocks 108, 110, and 112. This requested content may bethe merchant's webpage or content to be displayed in a merchant's nativeapplication executing on the consumer user device. In some cases, theconsumer and the merchant then complete the on-line transaction, asindicated by blocks 114 and 116. Completing the on-line transaction mayinclude the consumer selecting items or services for which the offerqualifies, providing payment information (e.g., identifying a creditcard account, a card-linked offer account, or an electronic walletaccount), and the consumer identifying the offer, for example, byentering a coupon code in a checkout page of the merchant. Examples ofcoupon codes include a relatively short, memorable string of text, likeless than 50 characters, or some other token, such as an image that theuser drags and drops into an interface on the checkout page. On-lineredemption of the offer is another example of a consumer interactiontracked in an interaction record in the tracking data store 42 of someembodiments.

In some cases, the on-line transaction is associated with the publisherat the affiliate-network system based on the record of the request foron-line redemption by the consumer. In some cases, the checkout page ofthe merchant system includes instructions for the consumer user deviceto retrieve content from the affiliate-network system, and that contentincludes scripts or other instructions that retrieve the identifier ofthe publisher from the persistent client-side memory of the consumeruser device, for instance, by reading a cookie or querying LocalStorage.Many browsers enforce a single-origin policy for security reasons thatonly permit access to such memory by the domain that wrote to thememory. Accordingly, the affiliate-network system may be able toretrieve the value identifying a publisher when the merchant cannot. Inother embodiments or use cases, the publisher may be associated with thetransaction based on a publisher-specific coupon code manually enteredby a consumer in the merchant checkout page or an identifier of thepublisher associated with the offer in a consumer's account, such as acard-linked offer account or an electronic wallet account used to payfor the transaction. In some cases, the association with the publisheris maintained in one of the above-mention interaction records.

The process 44, in some embodiments, further includes steps tocompensate the publisher and bill the merchant for the publisher'scontribution to the transaction. This may include reporting theassociation of the on-line transaction with the publisher from theaffiliate-network system to both the merchant system and the publisherserver (or publisher employees), as indicated by blocks 120, 122, and124. Reporting the association may include calculating the amount owedby the merchant to the publisher or the affiliate-network systemoperator. In some cases, aggregate counts or rates are reported, andspecifics of each transaction are maintained in memory for auditingthose amounts owed. In some cases, the amount owed for a giventransaction is a function of the total amount spent in a transactionbetween the consumer and the publisher, and a total amount of theconsumers purchase is reported by the merchant to the affiliate-networksystem, for example, directly in association with a session identifierthat is also tied to the consumer's request for content at checkout, orvia a request for content itself. Steps 122 and 124, as illustrated,complete the branch of decision block 88 of FIG. 3 for on-lineredemption of an offer in this example.

FIGS. 5 and 6 show a branch of process 44 for off-line redemption of anoffer following from node “C” of decision block 88 in FIG. 3. As noted,examples of off-line redemption include in-store redemption orredemption (or actions to facilitate redemptions) via other devices oraccounts. Upon a user interacting with offer content such that an intentfor off-line redemption is expressed, the consumer user device sends arequest for off-line redemption information to the affiliate-networksystem, as indicated by block 126 in FIG. 5. The received request mayinclude an identifier of the publisher that provided the offer to theconsumer user device. The received request may then be stored in theabove-mentioned tracking data store, as indicated by block 128, forexample, in a new one of the interaction records described above. Thecorresponding interaction record may identify the publisher from whichthe consumer user device receive the offer and the type of redemptioninformation requested, for example, whether the consumer requestedredemption information to be sent to a phone number as a text message,to an email account as an email, to the consumer user device in a formatsuitable for printing, to a card-linked offer account, or to anelectronic wallet account. The resulting interaction record may be usedto determine compensation for publishers when the offer is redeemed on adifferent consumer user device or in-store.

With many existing affiliate-network systems, crediting publishers foroff-line redemptions is difficult, because many such systems rely onclient-side cookies for offer tracking that are not available when theconsumer redeems the offer using a different consumer user device, adifferent account, or a printed copy of the offer. In some embodimentsof the presently described processes and systems, the interaction recordcan be used as a basis for compensating publishers in these othercontexts. Further, directing the request for off-line redemptioninformation to the affiliate-network system consolidates such recordswith a single entity that can interface between merchants and publishersto determine such compensation.

Depending upon the type of off-line redemption information requested,the affiliate-network system takes various actions. Upon determiningthat the consumer selected a send-to-text option, the process 44 maysend the offer via text message to a phone number specified by therequest, as indicated by blocks 130 and 132. In some cases, the offerinterface presented on the consumer user device includes a text-boxinput for the consumer to identify a phone number upon indicating thatthey wish to send the offer to a mobile phone as a text message. Thisphone number may then be sent to the affiliate-network system tocomplete the request for off-line redemption information. In othercases, a user profile is maintained (e.g., in client-side or server-sidememory) that includes the phone number, and the number is retrieved frommemory for sending information to a mobile phone. Sending the offer inthis context may include sending a shortened description of the offerappropriate for mobile phone (for example, a one sentence summaryfollowed by an offer code) or may include sending a hyperlink to theoffer, such as a relatively short URL that links to a webpage for theoffer. To accommodate a relatively small namespace afforded by shortURLs, some embodiments may expire URLs after some duration, for exampleone year, and reuse the same URLs.

Later selections of the URLs on recipient mobile phones may be receivedat the affiliate-network system. Received selections may spawn newinteraction records in the tracking data store that are associated withthe corresponding offer and publisher. In some cases, consumers may sendthe offer to multiple phone numbers, for example, the phone numbers oftheir friends, and publishers may be compensated for multipleredemptions, thereby incentivizing publishers and merchants to interactwith the affiliate-network system. Some embodiments may restrict therate at which offers are sent to phone numbers to avoid abuse of thesystem by those sending un-desired text messages to others, for example,by maintaining a count of text messages sent from a given consumer userdevice over some trailing duration, and determining prior to sending anew text message whether the count exceeds a threshold (e.g., 50 textmessages per day). In some cases, a listing of phone numbers for whichusers have indicated they do not wish to receive offers is maintained,and before sending a text, the recipient number is verified to be absentfrom this list.

Some embodiments of the process 44 include determining whethersend-to-email was selected on the consumer user device and, in responseto such a selection, sending the offer to an email account specified bythe request, as indicated by blocks 134 and 136. In some cases, theinterface for interacting with offers presented on the consumer userdevice presents a text-box input upon a user selecting a button forsending the offer to an email account, and the user-entered emailaddress is sent as part of the request to the affiliate-network system.In response to the selection, some embodiments may construct anemail-specific and publisher-specific visual presentation of the offerwith the above-described content-negotiation module 30 and send thatpresentation, for example, in an HTML formatted email, to the specifiedemail address. In some cases, a listing of email addresses for whichusers have indicated they do not wish to receive offers is maintained,and before sending an email, the recipient email addresses verified tobe absent from this list. Further, to reduce the likelihood of undesiredemails being received, some embodiments determine whether the consumeruser device has sent more than a threshold amount of emails within sometrailing duration, using a process like that described above for textmessages.

Some embodiments of process 44 determine whether the consumer selected aprint-offer interface on the consumer user device and, in response, sendfrom the affiliate-network system a print-formatted version of theoffer, as indicated by blocks 138 and 140. Step 140 may include thecontent-negotiation module 30 described above constructing or selectinga publisher-specific and print-format specific visual presentation of anoffer. In some cases, the print-formatted version of the offer includesa barcode, a QR code, or other optically-machine-readable identifier ofthe offer for presentation at a point-of-sale terminal and scanning, forexample, with a barcode scanner or an optical scanner by a sales clerk.Some embodiments create an offer-specific, a publisher-specific, aconsumer-specific, or a session-specific scannable code, such that aprintout of the offer, when scanned at a point-of-sale terminal, yieldsdata that can be tied to an offer, a publisher, a consumer, or a sessionwith the affiliate-network system. For example, as described below, themerchant system may scan the code and store the code in memory inassociation with a merchant's record of the transaction. Merchanttransaction records may also indicate the date and time, what waspurchased, the purchase amount, the offer(s) that was (or were) redeemedduring the purchase, and in some cases, the identity of the consumer.Some or all of the merchant record may be sent to the affiliate-networksystem to determine compensation of the publisher. In embodiments withpublisher or session-specific codes, the code may be stored in theinteraction record stored in step 128 to tie the publisher with thein-store redemption. In other embodiments, a merchant supplied code isrepeated for each offer or a relatively large number of offers, suchthat the scannable code does not, by itself, identify the publisher orsession. Some merchant systems are incapable of validating single-useoffer codes and can only validate a relatively small number of codesthat are re-used. In some use cases, some embodiments determinecompensation for the publisher based on the interaction record, forexample, in a compensation per print model.

Some embodiments of process 44 determine whether the consumer selected asend-to-card-linked-offer account option on the consumer user deviceand, in response to such a selection, send the offer to an accountspecified by the request via an API of the card-linked-accountadministrator, as indicated by blocks 142 and 144. Card-linked offersare digital coupons or other offers loaded a credit card, debit card, orstore loyalty card account, such that when the respective card ispresented during a transaction, the offer is redeemed based on theassociation of the offer with the account. In some cases, consumer'scard-linked offer account information is requested upon selection ofthis interaction with a web form or other request for input sent to theconsumer user device, e.g., with a request to a native applicationexecuting on the consumer device that manages the consumer's card-linkedoffer accounts. In some cases, the information sent to the API includesa command to load the offer to the appropriate account and an identifiereither identifying the interaction record stored in step 128 or anidentifier of the publisher that should be compensated in the event theoffer is redeemed using the corresponding card. These identifiers may beused to determine compensation for the publisher when the offer isredeemed using the card, and either the merchant or the operator of thecard-link-offer account may report this information to theaffiliate-network system after (e.g., upon) redemption.

The process 44, in some cases, further includes determining whether theconsumer selected an option to send the offer to an electronic walletand, in response to such a selection, sending the offer to anelectronic-wallet API specified by the request, as indicated by blocks146 and 148. Examples of electronic wallet accounts include client-sideelectronic wallets (e.g., special purpose native applications executingon client-devices and implementing electronic wallet functionality) andserver-side electronic wallets (e.g., systems that host consumer accountinformation on a server that consumers access with a client-side“thin-wallet” application). Some client-side electronic walletapplications are configured for payment via NFC communication with apoint-of-sale terminal and to provide payment information for onlinetransactions (e.g., by populating checkout forms). During a transaction,the electronic wallet may electronically convey information to theseller to facilitate payment, along with information about offers beingredeemed in some cases. Like the card-linked offer example above, thesent information may include a command to load the offer to theelectronic wallet account along with identifiers of the publisher or theinteraction record in the tracking data store. One or more of theseidentifiers may be used to determine compensation for the publisher, andthe merchant or the entity operating or interacting with the electronicwallet account may report these identifiers to the affiliate-networksystem after redemption of the offer.

Thus, a variety of different off-line redemption channels are supportedin the present example. And it should be noted that a variety of otherredemption channels are consistent with the present techniques. Forexample, consumers may instruct the affiliate-network system to send theoffer to social networking accounts of other consumers, such that theoffer is presented within their friends' social networking accounts. Inanother example, consumers may share offers by transferring the offersto another consumer's user device with, for instance, a “bump” interfaceby which consumers physically bump their phones together, or with anon-screen gesture or interaction that instructs the mobile devices toexchange information via Bluetooth™, NFC, or other wireless connectionswith other, proximate mobile devices. Or consumers may instruct theaffiliate-network system to send the offer to themselves via one of thechannels described herein at some later date (e.g., as a reminder) orupon some condition obtaining (e.g., when the respective consumer'smobile user device enters some pre-defined geo-fence, such as onesurrounding one of the stores at which the offer is redeemable or theirhome or work, as indicated by a publisher's native mobile applicationthat is executing on the consumer's device and is configured to reportlocation to retrieve such reminders). Each such request may generate arecord in the tracking data store 42 described above, such thatpublishers can be compensated for various types of consumer interactionswith offers that merchants find desirable.

Further, some embodiments may generate additional interaction records(or values in such records) tracing the path of an offer through a chainof consumers who share the offer with one another. In some cases,merchants or publishers may wish to reward consumers for sharing offersvia off-line interactions. To this end, some embodiments store ininteraction records a recipient identifier (or list of suchidentifiers). When a later interaction record is created for interactionby the recipient, existing interaction records are queried for thosethat include the recipient's identifier, and if the offer is the same,the earlier interaction record is updated with an identifier for thelater interaction record. By tracing a chain of interaction recordsthrough such identifiers (which may be referred to as “links” or“pointers”), merchants and publishers may determine compensation forconsumers who share offers, e.g., calculating an amount of compensationbased on an percentage amount purchased by those with whom the offer wasshared. In some cases, merchants or publishers may configure offerrecords that specify compensation at one or more links in a chain oftransaction records that depends on multiple-downstream sharing events(e.g., at a decreasing rate for each subsequent sharing event), suchthat a single consumer can potentially be compensated for a relativelywide distribution of an offer if their friends share the offer widely topeople who, then, themselves share the offer widely. In some cases, suchrecords may also be queried by merchants or publishers to targetmarketing efforts to those consumers who historically have beenrelatively effective at distributing offers.

After determining the type of off-line transaction, embodiments of theprocess 44 execute the offer-presentation configuration process 80described above with reference to FIG. 3, as indicated by block 80 beingrepeated in FIG. 5. In some cases, configuration includes formatting theoffer for the various implicated APIs and associating with the offerpublisher information to determine compensation, or configuring theoffer may include forming an email-appropriate visual presentation ofthe offer, or the above-mentioned text message presentations of offers.Templates specific to each configuration may be retrieved from memory,and the templates may be populated by retrieving resources and otherinformation related to offers, publishers, and merchants from a datastore.

Upon configuring the offer presentation, the process 44 proceeds throughnode “D” to FIG. 6, where the offer, as configured in the form of offercontent, is received at another consumer user device (e.g., a devicethrough which an email or text message is received) or account (e.g.,one of the above-mentioned card-linked offer accounts, electronic walletaccounts, social networking accounts, or the like), as indicated byblock 150. In some use cases, the “other” consumer user device is thesame user device used at a later time to access one of the recipientaccounts. Sometime after receipt, the other consumer user device oraccount may be used to present the offer at a point-of-sale terminal ata merchant's physical site (e.g., for in-store redemption), as indicatedby block 152. Or in some cases, the other consumer user device is usedto redeem the offer on-line, for example, using a URL linking to awebpage upon which the offer is presented, in which case, the process 44returns to node “B” described above in FIG. 4 and proceeds with thecurrent consumer user device.

In the case of in-store redemption, the offer information is received ata point-of-sale terminal that is part of the merchant system. Receivingthe offer may include a sales clerk typing in an offer code (e.g.,either as shown on a printout or displayed on a screen of a mobile userdevice presented by the consumer) or other identifier. Or receiving theoffer may include scanning an optically-machine-readable code (e.g.,scanning a bar code or QR code either on a printout or on a displayscreen of a mobile user device presented by the consumer). In some usecases, receiving the offer may include a wireless exchange between thepoint-of-sale terminal and a mobile user device (e.g., using near-fieldcommunication, infrared, Bluetooth™, or wireless area network connectionto transfer data, such as an offer identifier and in some cases paymentinformation, between a consumer's mobile device and the point-of-saleterminal). The transferred, scanned, or otherwise entered data mayinclude an identifier (or identifiers) associated with the offer (and insome cases, the affiliate-network and/or the publisher) and, in someimplementations, an identifier of the interaction record stored in step128.

The merchant system may complete the in-store transaction, as indicatedby block 156. Completing the transaction may include entering into thepoint-of-sale terminal identifiers of a plurality of different items orservices (e.g., scanned stock-keeping-units (SKUs) from barcodes),retrieving from memory of the merchant system prices for those items,calculating a total price for the transaction, and applying the offer tothe transaction, for example, calculating a discount for those items orservices to which the offer applies. Merchant transaction records mayalso include identifiers of the consumer or a financial account used bythe consumer, which some implementations may use to correlate thetransaction with, and reward, activities by the affiliate-network,publishers, and/or consumers. (The reader should note that the use of“and/or” does not imply that other uses of “or” are necessarily used inthe sense of an “exclusive or.”) In some cases, publishers arecompensated for the total amount of the purchase, even if the offeritself only applies to a subset of the goods or services that arepurchased. Thus some embodiments associate the total amount purchasedwith the offer redemption. The merchant system may store a transactionrecord in memory that includes a listing of the items purchased, theaffiliate-network, purchase amounts, a total purchased amount, and anidentifier of the offer, the publisher, the session with which the userreceive the offer, or a combination thereof.

The merchant system may send data describing the off-line, in-storetransaction to the affiliate-network system, which may receive thisdata, as indicated by blocks 158 and 160. In some cases, some or all ofthe merchant transaction record is sent. Sending the data may includeautomatically executing a process on the merchant system thatperiodically uploads the merchant records through an API of theaffiliate-network system, for example, nightly or hourly. Or someembodiments may upload the merchant records in real-time, for examplewithin minutes of the transaction. In some implementations, an employeeoperating a user device within the merchant system may manually takeaction to send the transaction record, for example, in a batch oftransaction records emailed daily to an administrator of theaffiliate-network system. The records received from the merchant may beparsed by the affiliate-network system and used to populatecorresponding interaction record in the tracking data store 42 describedabove.

Next, the affiliate-network system may associate the off-linetransactions with publishers (e.g., based on the data from the merchantand/or data collected by the affiliate-network in connection with thetransactions) and report the association to the publisher and themerchant, as indicated by blocks 162, 164, 166, and 168. Associating theoff-line transactions with the publisher may include calculating anaggregate amount owed by a given merchant to a given publisher based ontransactions associated with that publisher because of redemptions ofoffers identified to consumers by that publisher. Or, in another form ofassociating the transactions with the publisher, the affiliate-networkmay act as a financial intermediary, billing merchants, associating theoff-line transaction with the publisher, and compensating publishersbased on the transactions, such that the two groups need not interfacewith one another to transfer payment. For example, in some embodiments,the identifier discussed in paragraph 100 may only be unique to theaffiliate-network (rather than each publisher) so that the merchant mayassociate the transaction with the affiliate-network. In such cases, theaffiliate-network may associate the transaction with a publisher, orestimate the relative number of transactions that should be associatedwith a publisher based on data collected in connection with process 44.In some cases, records are maintained so that merchants and publisherscan audit the affiliate-network system.

In some implementations, multiple parties are compensated for atransaction. For instance, merchants or the affiliate-network may definecompensation models in merchant or offer records. The compensationmodels may specify an amount of compensation for each of severalpublishers who presented the offer to consumers (as indicated by theinteraction records), as some transactions are caused by repeatedexposure to offers. Some compensation models may divide a total rewardequally among each publisher, or some may allocate more credit to thefinal publisher or to those publishers whose presentation of an offerprecipitated a particularly desirable form of consumer interaction, suchas printing the offer. In some cases, compensation is calculated forboth consumers who shared an offer and publishers, e.g., calculatingpoints in a loyalty reward program for the consumer and a cash rewardfor the publisher.

Thus, some embodiments of process 44 compensate publishers for bothon-line and in-store redemptions, as well as redemptions that cross overonto other user devices or accounts (which generically may be referredto as “redemption channels”). As explained, some embodiments provide forrelatively wide distribution of offers by merchants across multiplechannels. Further, because some embodiments associate interactionrecords spanning multiple channels for redemption with a single offeridentifier, merchants and publishers can track activity relating tooffers across multiple channels and dynamically adjust their activitiesor content of the offer to enhance their performance, for example, upthe ranking of or increase the number of channels or discount amount foroffers that, in at least certain channels, are performing particularlywell, or terminating or reducing the discount amount for offers that arespreading more quickly or being redeemed in greater number than amerchant would desire when measured against activity across all channelsfor redemption. (Though, again, not all embodiments necessarily providethese benefits.)

The above-described processes are explained with reference to a singleoffer and with reference to alternate branches for on-line and off-lineredemption, but it should be understood that the steps of process 44 maybe repeated thousands of times per hour for thousands of offers, in somecases, concurrently among thousands of offers, thousands of publishers,and thousands of merchants for millions of consumers. Moreover, in someuse cases, affiliate-network systems become more useful as they acquirescale. Many merchants wish to have their offers distributed through manypublishers, and many publishers wish to have access to a wide array ofoffers. To support the desired scale, some embodiments may perform theprocess 44 with implementations of the affiliate-network system 12(FIG. 1) built with data centers that execute multiple instances of theabove-describe modules to support relatively large numbers of concurrentoperations.

As described above, the offer presentation configuration process 80 andcontent negotiation module 30 configure offer content based on variousparameters, such as those relating to the publisher and device oraccount through which the offer content will be accessed. To illustratethe resulting offer content, FIG. 7 shows an example of offer content170 configured for display in a relatively large display screen, DOMelement, or window. In some cases, the offer content 170 is web contentpresented within a web browser on a desktop computer, laptop computer, atablet computer, or the like. The illustrated offer content 170, in thiscase, includes various merchant resources associated with an offer and amerchant, including a merchant logo image 172 and a merchant banner 174(e.g., a div-box having a merchant selected color). The illustratedoffer content 170 also includes various resources and content specificto the offer, including a description of the offer 176, a summary of theterms of the offer 178, and a link to a more comprehensive descriptionof the terms of the offer 180.

The illustrated offer content 170 further includes user-selectableinterfaces 182 applicable to the offer. In this example, the interfaces182 include a print button 184, a text button 186, an email button 188,a card-linked offer button 190, and an electronic wallet button 192,which collectively constitute an exemplary set of off-line offerredemption interfaces. These interfaces may be used to facilitateredemption through another device (including a printer) or account.Further, the offer content 170 includes a button to show a coupon code194 for on-line redemption. In some cases, a coupon code is concealed orotherwise withheld from view to force the user to interact with theoffer content 170 to indicate interest in an offer before redemption.(Otherwise, a user may write down or memorize the offer code andmanually enter that code in a merchant's checkout page, therebypreventing the publisher from being credited with the transaction,though some embodiments also display the code initially.) The offercontent 170 may include scripts, such as JavaScript™, that execute upona user selecting one of the buttons (e.g., in response to an on-clickevent or an on-touch event), and those scripts may initiate theabove-described steps of process 44 that implement the requestedfunctionality.

The offer content 170 may also include content specified by thepublisher, including a banner 196 of a color selected by the publisherto match the publisher's branding and an image of the publisher's logo198, along with text and links associated with the publisher's website(or corresponding API calls to a publisher's native application).Further, the URI 202 with which the offer content 170 was retrieved fromthe affiliate-network system 12 includes a domain of theaffiliate-network system 204, the name of the publisher 206, the name ofthe merchant 208, and an identifier of the offer 210. In some cases,this URI is provided to consumer user devices, as described above, sothat consumer interactions can be tracked across multiple channels bycentralizing requests with the affiliate-network system 12. Further,including the publisher's named in the URI and including publishercontent in the offer content 170 allows multiple publishers to maintaindistinct brands, while using a centralized service to host offercontent.

FIG. 8 shows another example of offer content 212 configured for displayon a relatively small display screen, DOM element, or window. In somecases, the offer content 212 is obtained with reference to the same URI202 as the offer content 170 of FIG. 7. This example of offer contentincludes a merchant image 214 associated with the offer or the merchant,which may be a lower-resolution version of the image 172 (FIG. 7) toaccommodate the smaller display area. The illustrated offer content 212also includes a banner 216, which may be of a color selected by themerchant or the publisher, depending upon the implementation. The offerdescription 176 and summary of terms 178 is also used in the offercontent 212, though some versions may store and display a shorterversion of the description or terms for smaller displays. In thisexample, the offer content 212 includes a different set of offerinterfaces 218, as specified by the above-mentioned templates and theoffer record for the offer being displayed (e.g., some offers are onlyredeemable on-line). In this case, the interfaces include a card-linkedoffer button 190, and the electronic wallet button 192 to facilitatein-store usage of the offer by sending the offer to an account withwhich the consumer can pay for a transaction and apply the offer.Interfaces also include buttons 192 and 188 showing the offer code oremailing the offer, respectively. Further, this example includes anoptically scannable image 220, in this case, a barcode image, thoughother types of such images may be used, including temporally changingpatterns (e.g., codes transmitted by flashing a pattern on a displayscreen), or QR codes. As noted above, some embodiments may dynamicallygenerate single-use offer codes, and the barcode image 220 may bedynamically generated, for example at the time the offer content 212 isrequested. The offer content 212 also includes the publisher links andinformation 200.

The two versions of offer content 170 and 212 may both be retrievedusing the same URI 202 and may be specified by different templatesselected based on the type of consumer user device, account, or displaywindow in which the offer will be displayed. Those templates may bepopulated, in part, with resources and other content provided by thepublisher, such that the presentation is customized to be in accordancewith the publisher's brand, and the offer content 170 and 212 generallymay be selected in view of the size of display and likelihood that thedisplay will be carried into a store to be presented at a point-of-saleterminal. Other forms of offer content may accommodate APIs specifiedfor adding the offer to a card-linked offer account or an electronicwallet. Further, some versions may include templates for HTML formattedemails and text formatted emails.

As noted above, centralizing tracking of interactions with offers acrossmultiple channels allows merchants and publishers to track theperformance of a given offer through multiple forms of redemption andother interactions. FIGS. 9 and 10 show examples of analytics generatedbased on the above-described interaction records. FIG. 9 shows ascreenshot of merchant metrics 222 by which a merchant can view (e.g.,via a web browser) and interact with various statistics associated withredemptions of (or other interactions with) offers across multiplechannels. Similarly, FIGS. 10A and B show portions of a screenshot ofpublisher metrics 224 by which publishers can perform similar analyses.The screenshots 222 and 224 include various interfaces by whichpublishers and merchants can query data specific to offers, date ranges,merchants, publishers, consumer user device operating system, channel,geographic distribution, and the like. Using responsive data, merchantsand publishers may adjust their strategies related to offers to improvetheir performance.

In some embodiments, the interaction records may be used to dynamicallyadjust the terms of offers with a process 226 based on consumerinteractions both in-store and on-line. The process 226 may be performedby the above-described affiliate-network system 12 of FIG. 1, thoughembodiments are not limited to that implementation. In some cases, theprocess 226 is performed by a data processing apparatus executing codespecifying steps of process 226 in a non-transitory, machine-readable,tangible medium, examples of which are described below with reference toa computer system of FIG. 12. Dynamically adjusting the terms of offersis expected to become more desirable as merchants issue increasingnumber of offers redeemable across multiple channels and being ofincreasing complexity, for example, varying in geographic applicability,having a shorter term, using A/B testing, and applying to narrower setsof conditions.

Adjusting the terms of offers can refer to a number of differentactivities that change the universe of offers presented to consumers. Insome cases, dynamically adjusting the terms of an offer includescanceling the offer, for example, by ceasing to send the offer topublishers, or by sending a message to publishers to stop publishing anoffer that has already been sent to them. In some cases, dynamicallyadjusting the terms of an offer includes automatically generating newoffers based on an existing offer (e.g., changing one or two terms orattributes—including images and other resources—of an existing offer ina merchant-specified fashion), such that subsequent publisher requestsretrieves the new, dynamically generated offer, and the previouslypresented offer is no longer published. Thus, consumers who, forexample, printed an earlier iteration of an offer may have a print-outwith a barcode that ties to the previous terms of the offer, prior todynamic adjustment of the new terms, while a consumer who prints a newversion of the offer after dynamic adjustment will receive a differentbarcode, tied to the dynamically adjust the terms. These terms may besent to a merchant's system (e.g., via a merchant API) to update amerchant database for applying the offer in-store with the new terms.

The process 226, in this embodiment, begins with obtaining adynamic-offer algorithm specified by a merchant, as indicated by block228. In some cases, merchants specify this algorithm by, for instance,entering threshold rates or amounts of particular types of consumerinteractions with a given offer (or collection of offers) and indicatingactions to be taken upon those thresholds being exceeded, for example,requesting an alert be sent to the merchant, requesting that the offerno longer be published, or requesting that a new offer with less or moregenerous terms be generated and published instead of the current offer.For instance, the algorithm may indicate that a given offer is to bereplaced with a new offer with a 5% smaller discount or shorterexpiration date in response to the amount of consumer interactions viasocial-network sharing exceeding a threshold of 50,000 suchinteractions. Or embodiments may specify that an offer related to wintercoats is to be issued and valid in geographic areas in which the weatherforecast calls for temperatures below 45-degrees Fahrenheit within thenext 5 days.

The process 226, in some cases, further includes obtaining feed-forwardparameters of the dynamic-offer, as indicated by block 230. Somemerchants may wish to adjust the terms of offers based on data externalto the affiliate-network systems. For example, a merchant may specifythat an offer be initiated or terms of an offer be adjusted in responseto a change in the weather (for instance, to offer a discount on raingear when rain is expected), a particular result in a sporting event(for instance, to discount jerseys of a winning or losing footballteam), or based on an amount or rate of occurrence of some term in adata-feed indicative of on-line activity, like the occurrence of a termin search queries or social network data feeds, indicating that aparticular brand or item has become popular (for instance, specifying adiscount on a particular brand of shoes in response to that brand nameoccurring above a threshold rate within search queries on-line). Not allembodiments, however, obtain or use such feed-forward parameters, whichis not to suggest that any other feature cannot also be omitted.

Some embodiments of process 226 further include obtaining feed-backparameters of the dynamic-offer, such parameters including dataindicative of both on-line usage and off-line usage of the offer, asindicated by block 232. The feed-back parameters may include theabove-mentioned interaction records, for example, a rate, an amount, ortypes of such interaction records. In one case, a merchant may specifythat the terms of an offer are to be adjusted in response to more than athreshold amount of interactions indicating a consumer has sent theoffer to more than one recipient to limit the spread of an offer that isparticularly generous. In another example, merchants may request analert when more than a threshold rate of interaction records aregenerated for a given offer, for example, more than five standarddeviations of the typical rate of accumulation of offer interactionsthat occurs for that merchant. Such anomalous rates may be indicative ofan error in the offer, for example, offering a price discount that islarger than what the merchant intended to offer, in which case, themerchant may wish to dynamically or manually adjust the terms of thatoffer.

The process 226, in some embodiments, further includes creating a newversion of the offer with terms adjusted based on the feed-forward andthe feed-back parameters, as indicated by block 234. As noted above,this step may include canceling an offer, sending a message topublishers requesting that they cease publishing an offer, and creatinga new offer with different terms, for example, with a 5% smallerdiscount, a 5% larger discount, a five dollars smaller discount, a fivedollar larger discount, a shorter expiration date, or a longerexpiration date. Further, as noted above, some merchants may specifythat an alert is to be sent to the merchant, so the merchant canmanually intervene.

The process 226 may further include storing the new version of the offerin an offer data store, as indicated by block 236. Storing the newversion of the offer may include creating a new offer record in theabove-described data store 40 of FIG. 1, for example by cloning theexisting record upon which the feed-back is based and adjusting theterms in the new record based on the instructions provided by themerchant in the dynamic-offer algorithm. Alternatively, storing the newversion of the offer may include changing a record of an existing offerto indicate that the offer is to no longer be published.

Thus, some embodiments of the process 226 allow merchants to automatethe management of offers and respond relatively quickly to changes ininteractions with offers and to changes in likely demand for offers,across multiple channels of offer redemption. Further, some merchantsmay use the automation process to A/B test offers, issuing offers withlow-thresholds before cancellation, and measuring the response ofconsumers to differences between offers, refining offer terms and offercontent to increase efficacy. The process 226 can be used with theabove-described affiliate-network system 12 and process 44, which aresuited to producing feed-back data by which offers may be relativelyreliably automatically changed, but the process 226 is not limited tothose implementations and is independently useful in other environments.

In other embodiments, geographic location data may be used in thegeneration, presentation, and other aspects of offers. For example, asdescribed further below, offers may be location-restricted to certainmerchant locations or geographic areas. Additionally, the presentationof offers may be based on location data, such as a geographic radius orother area around a user's location. Moreover, the geographic locationdata may enable greater control and configuration of offers and a moreaccurate evaluation and prediction of offer performance.

As mentioned above, in some embodiments the merchant data store 36 isconfigured to store data about merchants that use the affiliate-networksystem 12. In some embodiments, such merchant data may include merchantlocations, e.g., brick-and-mortar stores of a merchant. FIG. 12 depictsa process 1200 for providing merchant locations to the affiliate networksystem 12 in accordance with an embodiment of the present invention. Asis illustrated in FIGS. 2-6, a first column of the flow chart of FIG. 12corresponds to the merchant system 16 and a second column of the flowchart of FIG. 12 corresponds to the affiliate-network system 12.

In some embodiments, the process 1200 includes the merchant system 16sending merchant locations to the affiliate-network system 12, and theaffiliate-network system 12 adding those merchant locations to amerchant data store, as indicated by blocks 1202 and 1204. As indicatedby block 1206, the merchant system 16 may also send additional merchantlocation parameters 1206 to the affiliate-network system 12. Theadditional parameters may include information about the merchantlocations, such as location hours, point-of-sale capabilities, merchantlocation attributes, and so on. The location attributes may includelocation-specific capabilities relevant to the merchant or type oflocation. For example, for a home improvement and construction merchant,the location attributes may include whether a location offers toolrentals, vehicle rentals, key cutting, propane exchange, and so on. Insome embodiments, the additional parameters may include an offerdistance threshold (e.g., a discoverability radius) for the presentationof offers of the merchant. In some embodiments, the distance thresholddefines the permissible distance from a location that merchant offershaving offer location data may be presented. For example, alocation-restricted offer having offer location data that is outside ofthe distance threshold from a given location may not be published to aconsumer user device whereas a location-restricted offer having offerlocation data that is within the distance threshold from a givenlocation may be published to the consumer user device, as describedfurther below. In some embodiments, each merchant included in themerchant data store may have a default offer distance threshold that maybe overridden by the merchant or on a per-offer basis.

In some embodiments, the merchant locations received by theaffiliate-network system 12 may be processed by the affiliate-networksystem 12, such as by standardizing the merchant locations. Suchstandardization may include replacing or associating merchant locationswith a geocode, such as coordinates (e.g., longitude and latitude) of ageographic coordinate system. The geocode may subsequently be used as amerchant location identifier for a merchant location, or a separatemerchant location identifier may be generated. Additionally, asdescribed further below, the merchant locations may be grouped based onthe location attributes received from the merchant or locationattributes created by the affiliate-network system. Moreover, merchantlocations may be associated with designated market areas (DMAs). As usedherein, the term DMA refers to a designated market area as defined byNielsen Holdings N.V. of New York, N.Y. The geocodes, additional oralternative merchant identifiers, the location attributes, groups ofmerchant locations, and associated DMAs may be stored in the merchantdata store 36.

As mentioned above, in some embodiments the merchant locations areprovided through a website interface hosted by the affiliate-networksystem 12. This website may include interfaces by which a merchant cansubmit, modify, and remove merchant locations (or an administrator ofthe affiliate-network system may enter those merchant locations onbehalf of the merchant). Additionally, the website may enable a merchantto add the additional parameters mentioned above, such as the merchantlocation attributes for a merchant location. In some embodiments, thewebsite may receive merchant locations in any one of or several formats,such as a street address, geographic coordinates, and so on.

Next, the merchant system 16 may send, in addition to the offerparameters as described above in [0045] and [0065], offer locationparameters that specify an offer the merchant wishes to have distributedto the affiliate-network system 12, as indicated by blocks 1210 and1212. The offer location parameters may include various types oflocation specifications for an offer. For example, in some embodiments,location specific offer parameters may include restriction of an offerto one or more merchant locations for redemption, restrictions of anoffer to one or more geographic locations (e.g., states, provinces,settlements such as cities) for redemption, restriction to one or moreDMAs for redemption or publication, or any combination thereof. However,in other embodiments, a location specification may additionally oralternatively relate to other types of actions associated with an offer.In some embodiments, the affiliate-network system 12 may define thelocation restrictions for an offer after receiving offer parameters froman offer. Moreover, it should be appreciated that a merchant may sendboth non-location-restricted offers and location-restricted offers tothe affiliate-network system 12.

After the offer is received at the affiliate-network, the offer may beadded to an offer data store of the affiliate-network system 12, asindicated by block 1214. In other embodiments, the offer locationparameters may be used by a merchant to define where the offer is to bepromoted (e.g., provided to users for viewing in response to a userrequest or pushed to users) and, in some cases, such offers may not haveany redemption restrictions. In some embodiments, the offer locationparameters may include an offer-specific distance threshold that definesthe permissible distance from a location that the offer may bepresented. In some embodiments, the offer-specific distance thresholdfor an offer may override the offer distance threshold discussed above.

In some embodiments the offer data store 40 may store some or all of thedata of an offer record described above in paragraph [0045] and theoffer location parameters mentioned. Thus, for example, in someembodiments an offer record may include the offer variant, i.e., whetherthe offer has location data, whether location data exists but the offeris not location-restricted, and whether the offer islocation-restricted. Additionally, in some embodiments, an offer recordmay store merchant location identifiers associated with an offer. Thus,when a merchant submits offer location parameters, a corresponding offerrecord may include those merchant location identifiers reflecting thesubmitted location parameters. In some embodiments, the offer record maystore one or DMAs associated with an offer. In such embodiments, theDMAs associated with an offer may be specified by the merchant in theoffer location parameters or the DMAs associated with an offer may bedetermined by the affiliate-network system 12 based on, for example, themerchant location identifiers associated with an offer.

FIG. 13 is a flow chart that depicts a process 1300 for, in someembodiments, the use by the publisher server 18 of offers and locationdata in accordance with embodiments of the present invention. Asdescribed above and similar to the flow charts illustrated in FIGS. 2-6,a first column of the flow chart corresponds to the affiliate-networksystem 12, a second column of the flow chart corresponds to thepublisher server 18, and a third column of the flow chart corresponds tothe consumer user device 20.

As shown in FIG. 13, the process 1300 includes, in some embodiments,receiving at the publisher server 18 a request for published offers fromthe consumer user device 20, as indicated by blocks 1302 and 1304. Insuch embodiments, device location data 1306 is also provided with therequest for offers. As will be appreciated, the device location data1306 may include an estimated location for the consumer user device, asestimated from communication with a satellite-based positioning system(e.g., GPS), Wi-Fi based positioning, or other location estimations. Inother embodiments, the location of the consumer user device may bedetermined from an IP address or other token associated with consumeruser device. In such embodiments, the location estimate may be performedby the publisher server 18 or another entity utilized for such locationdeterminations (e.g., a service that provides IP address geolocation).In some embodiments, as noted above, the consumer user device 20 mayinclude a vehicle-mounted computer and subsequent publication of offersdescribed below may be displayed on a display of the vehicle-mountedcomputer as a user drives the vehicle in a geographic area. In someembodiments, a request for offers from a consumer user device 20 may beperiodically refreshed as the location of the consumer user device 20changes (e.g., after a threshold location change), such as when avehicle is driven around a geographic area.

In other embodiments offers may be “pushed” to the consumer user device20 from the publisher server 18 without an explicit request from theconsumer user device (although, in some embodiments, the user may notreceive pushed offers until opting-in to such functionality). In suchembodiments, the publisher server 18 may first obtain the devicelocation 1306 for the offer push, as indicated by block 1308. As shownin FIG. 13, the device location 1306 may be sent to and obtained by thepublisher server 18 by the publisher server for the offer push.

Next, the publisher server may request offers from the affiliate-networksystem 12, and the affiliate-network system 12 may receive this requestthrough an API at the affiliate network system, as indicated by blocks1310 and 1312. The API may provide for the request of offers withoutoffer location data, offers with location data, or both, and may providefor the request of the offer location data for each offer. As notedabove in paragraph [0065], responsive offers may be determined based onpublishers' criteria, merchants' constraints, or a combination thereof.

In some embodiments, the publisher server may request offers without anyregard to the location data associated with offers, as described aboveand illustrated in FIG. 3. However, as shown in FIG. 13, in someembodiments, the publisher server may request offers based on forexample, location criteria 1314. The location criteria 1314 may includecriteria based on the consumer user device location 1306 or othercriteria. In some embodiments, the location criteria may include: one ormore geographic areas (e.g., as defined by a geographic radius aroundthe consumer user device location), one or more specific locations(e.g., a merchant location), one or more DMAs, or other suitablelocation criteria.

In some embodiments, the affiliate-network system 12 may determine whichoffers match the location criteria 1314 by using the offer location dataassociated with each offer, as indicated in block 1316. For example, ifthe location criteria include a radius around a location (e.g., theconsumer user device location), the affiliate-network system 12 maydetermine the offers having offer location data (e.g., merchantlocations) within the geographic radial area. For example, those offersredeemable at specific merchant locations within the geographic area maybe determined to match the location criteria. In some embodiments, thelocation criteria 1314 may include or be compared against an offerdistance threshold for a merchant or an offer-specific distancethreshold for presentation of an offer. In some embodiments, thelocation criteria 1314 may include one or more DMAs (e.g., a DMA thatincludes the location of the consumer user device 20). In suchembodiments, the DMAs associated with offers may be compared against thelocation criteria 1314 to determine matching offers.

In response to the request, as mentioned above, the affiliate-networksystem 12 may identify responsive offers (e.g., from the offer datastore 40 of FIG. 1) and send the offers with offer location data to thepublisher server 18, as indicated by blocks 1318 and 1320. As notedabove, offers provided to the publisher server may include offers havingno location data, offers having offer location data but no locationrestrictions, and offers having offer location data and locationrestrictions. As noted above, in some embodiments sending an offerincludes sending some or all of an offer record stored in the offer datastore 40. For example, offers having offer location data may be sentwith merchant location identifiers associated with the offer. Asdescribed above in paragraph [0071], sending the offers may includecreating a publisher-specific URI for each offer.

As mentioned above, in some embodiments, the request and receipt ofoffers by the publisher server 18 may be performed in real-time inresponse to the request from the consumer user device 12 (block 1304) oran offer push (block 1308). In other embodiments, the request andreceipt of offers by the publisher server 18 may be performedperiodically (for instance, as a batch process run hourly or daily). Inyet other embodiments, the request and receipt of offers may be a hybridof real-time and periodic processes (for example, an initial batchprocess retrieval of offers may be supplemented with real-time retrievalof offers in response to a request from the consumer user device 12).

The publisher server 18 may send the URIs of the matching publishedoffers (e.g., publisher-and-offer-specific URI) to the consumer userdevice 20, which may receive the offers for publication (e.g., apublisher-and-offer specific URI), as indicated by blocks 1322 and 1324.In some embodiments, the URI sent to the consumer device may includeoffer location data that may be used to display the offer based onlocation, as described further below. In some embodiments, as mentionedabove in paragraph [0075], instructions to display information about theoffers to the consumer are also sent to the consumer user device 20. Inother embodiments, as described above in paragraph [0075], the publishermay send instructions to the consumer user device 20 to retrieveinformation identified by the URIs without further interaction by theuser (or these instruction may be provided by a native applicationexecuting on the consumer user device 20).

The consumer user device 20, in some embodiments, requests offer contentidentified by the URIs from the affiliate-network system 12, asindicated by block 1326. As described above in paragraphs [0075]-[0079],in some embodiments the request for offer content at theaffiliate-network system initiates the offer presentation configurationprocess 80 having various steps 76, 78, 81, and 82 illustrated in FIG.3. After receiving the offer content, the consumer user device 20 maydisplay the offer content, such as on a computer-implemented geographicmap, as indicated by block 1328. The display of the offer content on thecomputer-implemented geographic map may be responsive to instructionsreceived from the publisher server or instructions retrieved viaidentification information in the URI. The instructions may includeinstructions for the display of the offers on a computer-implementedgeographic map, as described below in FIG. 14. Next, as also describedabove, user interaction with the offer content at the consumer userdevice may be received, as indicated in block 1330. Depending on thetype of the user's interaction, different paths for on-line or off-lineredemption may be followed, as indicated by decision block 1332. In suchembodiments, if on-line redemption is selected the process proceeds tothe node labeled “B” as described above and depicted in FIG. 4; if offline redemption is selected, the process proceeds to the node “labeled”C as described above and illustrated in FIG. 5.

In some embodiments, offers may be provided as a digital circular (e.g.,a digital version of a printed circular of offers). In such embodiments,a digital circular may be created (e.g., by the affiliate-network system12 or the publisher server 18) from the offers and offer location dataprovided by the affiliate-network system 12. A digital circular may begenerated for a specific geographic location or DMA using the offerlocation data for offers, such that offers restricted or targeted tovarious merchant locations or DMAs may be included in the digitalcircular if they are within the specific geographic location or DMA. Insome embodiments, the generation of a digital circular may beaccomplished at the consumer user device in response to instructionsreceived from the publisher server or instructions retrieved viaidentification information in the URI.

FIG. 14 depicts a screen 1400 of the consumer user device 20illustrating the display of offers on a computer-implemented geographicmap 1402. In some embodiments, the computer-implemented geographic mapmay be displayed as a webpage in a browser according to instructionsreceived from, for example, the publisher. In other embodiments, thecomputer-implemented geographic map may be displayed in a native ornon-native application executing on the consumer user device 20. Forexample, in some embodiments the computer-implemented geographic map1402 may be displayed in a native maps application executed by theconsumer user device 20. In such embodiments, offer information may bemade available via an API for use by applications executed by theconsumer user device. The screen 1400 may include a status bar 1404 thatincludes various icons that provide information, such as the time,network connectivity, and battery power of a battery of the consumeruser device. In some embodiments, information about offers may also bedisplayed in the status bar 1404 (e.g., as notifications in the statusbar).

The computer-implemented geographic map 1402 may include controls 1406,such as a pan control 1406A and a zoom control 1406B. It should beappreciated that these controls are merely non-limiting examples andother embodiments of a computer-implemented geographic map may includealternative or additional controls. For example, in some embodiments thecomputer-implemented geographic map 1402 may be displayed on a touchscreen of the consumer user device and control of thecomputer-implemented geographic map 1402 may be accomplished via touchinput received from a user of the consumer user device.

In accordance with the embodiments described above, offers 1410 (e.g.,Offer 1, Offer 2, and Offer 3) may be displayed on thecomputer-implemented geographic map 1402 (e.g., as points-of-interest(POIs), such as via interactive markers 1412. each marker 1412associated with an offer 1410 may indicate the location determined fromthe location data associated with each offer as provided by theaffiliate-network system 12 and processed by the publisher server 18. Insome embodiments, as mentioned, above, a URI of a published offer sentto the consumer user device 20 may include offer location data or,alternatively or additionally, offer location data is requested from theaffiliate-network 12 with the offer content.

As shown in FIG. 14, for example, the location of the first offer 1410Amay be indicated by the marker 1412A, the location of the second offer1410B may be indicated by the marker 1412B, and so on. In someembodiments, additional markers of additional offers may be viewed whena user pans and/or zooms the map to display additional geographic areas.As mentioned above, in some embodiments a predetermined number of offersmay be displayed on the computer-implemented geographic map 1402, andthe user may be able to select the display of additional offers in thegeographic area displayed on the computer-implemented geographic map1402. Thus, in such embodiments, the offers 1410 shown in FIG. 14 maynot represent all of the offers available in the geographic locationdisplayed on the computer-implemented geographic map 1402.

In some embodiments, the markers 1412 may be selectable (e.g., clickableor touchable) such that a user may view additional details about anoffer by selecting the marker. For example, as shown in FIG. 14, theuser may select the marker 1412C associated with offer 1410C to viewadditional information about Offer 3. In some embodiments, selection ofthe marker 1412C may result in the display of an offer detail window1416. In other embodiments, selection of the offer marker 1412C mayresult in the display of a webpage having offer details or other userinterface element. In some embodiments, selection of the offer marker1412C may eventually result in the display of a merchant webpage thatenables a user to redeem the offer 1410C associated with the selectedmarker 1412C. The offer detail windows 1416 may display offer content,such as the offer name (“Offer 3), offer description (“Offer details)”and information about the location associated with the offer (“Merchantlocation”.) For example, in such embodiment the “Merchant location” mayprovide an address, contact information, and other information of themerchant associated with the offer 1410C. As noted above, various otheroffer content may be displayed such as a merchant logo image, a merchantbanner, a summary of the terms of the offer, a link to a morecomprehensive description of the terms of the offer, content specifiedby the publisher, and so on.

FIG. 15 depicts a process 1500 for processing merchant locationsprovided by the merchant system 16 in accordance with an embodiment ofthe present invention. In some embodiments, the process 1500 is executedby the affiliate-network system 12. In some embodiments some steps ofthe process 1500 may be executed by the merchant system 16 or thepublisher server 18. For example, in some embodiments the merchantsystem 16 may standardize merchant locations (e.g., to a geographiccoordinates) before sending to the affiliate-network system 12.

Initially, the merchant locations are obtained, as indicated in block1502. For example, merchant locations may be obtained from a merchantsystem 16. Next, the merchant locations may be standardized, asindicated in block 1504. For example, as mentioned above, the merchantlocations may be received as an address and standardized to postaladdress, geographic coordinates, or other formats. In some embodiments,merchant locations may be associated with DMAs. For example, a merchantlocation within a specific DMA may be associated with that DMA. In someembodiments, the association may include an evaluation of theappropriate DMA for a merchant location if multiple designated marketareas are possible. For example, if a merchant location on the borderbetween two DMAs, the merchant location may be evaluated the particulardesignated market area the merchant location is associated with.

Next, merchant locations may be associated with location attributes, asindicated in block 1504. As mentioned above, such location attributesmay include location-specific capabilities relevant to the merchant ortype of location. A merchant location may be associated with noattributes or one or more attributes depending on the informationavailable to the affiliate-network system. In some embodiments, some orall of the location attributes may be provided by the merchant system.As mentioned above, in some embodiments the affiliate-network system mayprovide an application (e.g., a web application having a user interfacewebpage) for a merchant to submit merchant locations and, in someembodiments, location attributes.

In some embodiments, merchant locations may be grouped or clusteredbased on location attributes. In some embodiments, the grouping mayperformed in response to a request from a publisher server, a consumeruser device, or other entity. In some embodiments, after obtainingoffers from the affiliate-network system 12, the publisher server 18 maygroup merchant locations in response to a request from the consumer userdevice 20. For example, Merchant locations having a “tool rental”attribute and capable of providing for redemption of such offers maygrouped together and provided as the provided as the offer locations fora location-restricted offer for tool rentals.

In some embodiments, the location data associated with offers may beused to improve feedback, evaluation, and prediction of offers. FIG. 16depicts a process 1600 for offer feedback using offer location data inaccordance with an embodiment of the present invention. Initially, asdescribed above, users may interact with offers, including offers havinglocation data, as indicated by block 1602. The user interaction mayinclude receiving offers, viewing offers, and redeeming offers. Activityof a specific user may not be available for feedback unless the user hasopted-in to provide such activity to another entity, such as thepublisher, affiliate-network, merchant, or other entity. Moreover, suchuser activity may be appropriately anonymized such that the identity ofthe user is removed from the user activity used in subsequentprocessing.

The user activity may generate data related to offers, such as off-linetransactions with redemption locations, as indicated by block 1604, andoffer views with viewing locations, as indicated by block 1606. Theperformance of an offer may be analyzed using this activity data, asindicated by block 1608. For example, the viewing locations may becompared against the redemption locations to provide an indication ofoffer distribution vs. offer redemption. Various other comparison oranalysis may be performed using the offer redemption activity and theoffer viewing activity. In some embodiments, these analyses may includeconsideration of additional user activity, such as a user saving anoffer for future use, redemption of an offer using an e-wallet, checkoutactivity using an offer (e.g., from within a publisher applicationexecuting on the consumer user device 20), and so on.

In some embodiments, the offer performance analysis described above maybe used to adjust offer parameters, either of an existing offer orfuture offers, as indicated by block 1610. In some embodiments, anexisting offer may be adjusted to facilitate increased viewing,increased redemption, and so on. As shown in FIG. 16 for example, offerparameters (e.g., the offer type, an expiration date, a percentagediscount of the offer, a minimum purchase value, a dollar amount offfrom the offer, and so on) may be adjusted based on the performanceanalysis. For example, if a merchant notices views at or near variousmerchant locations and desires to increase redemption rate, the merchantmay increase the percentage discount of the offer. In another example,the offer location parameters may be adjusted based on the offerperformance analysis, as indicated by block 1614. For example, thepossible redemption locations of a location-restricted offer may beexpanded to increase redemption rates or in response to offers viewsoutside the initial location restrictions. In another example, thedirect market areas of an offer may be adjusted, as indicated by block1616. In some embodiments, for example, the DMAs of an offer may beadjusted to attack competing merchants in competitively vulnerable DMAs.

In some embodiments, the user activity data may be used to predictfuture offer performance, as indicated by block 1618. For example, amodel of offer performance having parameters such as offer type, offerlocation data, and so on may be generated from the offer data and useractivity data and used to predict the performance of future offers. Theoffer performance prediction may be used to generate new offers forvarious purposes, such as to attach competitively vulnerable geographicareas or DMAs. In some embodiments, possible offer parameters may besubmitted to the affiliate-network system 12, such as through a websiteinterface hosted by the affiliate-network system 12, and the predictedperformance of the offer may be provided to a merchant for evaluation.

In some embodiments, the data associated with offers may be used toidentify offers, merchants, or both having significant redemptionbreakage. FIG. 17 depicts a process 1700 for identifying redemptionbreakage of merchants in accordance with an embodiment of the present.Initially, an offer 1702 is distributed to users in accordance with thetechniques described above. As noted above, the offer may include anoffer having offer location data and may have location-restrictionsidentifying merchant locations for redemption. Users receiving the offermay initiate a redemption attempt of the offer through various actions.For example, in some embodiments a user may select (e.g., click) a“Redeem Now” button presented with the offer content displayed on theconsumer user device 20. In other embodiments, redemption initiation mayoccur through various other actions, including interactions with otheroffer content. The locations of users' redemption initiations for theoffer may be obtained, as indicated by block 1704. For example, alocation-restricted offer may be pushed to a consumer user device whenthe device is in a specific location, and the device location may besent to the publisher, the affiliate-network system or both. In someembodiments the request sent in response to a user selection forredemption initiation may include location information, such that theaffiliate-network system 12 that receives the request also receives thelocation corresponding to the user redemption initiation. As notedabove, consumer user device locations may be anonymized by hashinginformation from the consumer user devices 20 or other techniques.

The number of successful in-store redemptions occurring at merchantlocations may also be obtained, as indicated by block 1706. For example,as discussed above, the transaction corresponding to redemption of anoffer at a merchant POS may be transmitted to the affiliate-networksystem 12. The number of redemptions for an offer may be stored andobtained from a data store of the affiliate-network system 12.Additionally, in some embodiments the locations of the successfulin-store redemptions are also obtained (e.g., the merchant locationwhere a successful in-store redemption occurred). The redemption successrate of the offer may be determined from the number of redemptioninitiations and successful off-line redemptions, as indicated by block1708. In some embodiments, the redemption success rate may also bedetermined per merchant location, per redemption initiation location, orother basis. Moreover, in some embodiments the location of redemptioninitiation and the locations of successful redemptions may be used inthe determination of a redemption success rate (e.g., only successfulredemptions within a specific distance of, or geographic area including,the redemption initiation locations may be used in the determination).

Merchant transaction data over a time period may be obtained, asindicated by block 1710. For example, merchants may send transactiondata from a time period to the affiliate-network system 12, eitherperiodically or upon request from the affiliate-network system 12. Aswill be appreciated, the merchant transaction data may includetransactions including redemption of the offer and other transactions.The time period of merchant transactions may coincide with or includethe time period for which the offer was valid. Next, the merchantshaving significant redemption breakage, e.g., redemption breakage abovea redemption breakage threshold, may be determined, as indicated byblock 1712. The redemption breakage threshold may be based on historicaldata for similar offers, a baseline threshold for all offers, amerchant-specific threshold, an offer-specific threshold, or othersuitable thresholds. In some embodiments, the number of redemptioninitiations may be compared to the number of successful redemptionsreceived from the merchant and the total merchant transactions thatimplicate the offer to determine the redemption breakage for the offer.For example, if the consumer arrived at a merchant POS ready to redeeman offer but the merchant cashier manually discounted the sale orentered a different code (as opposed to scanning or entering a codeassociated with the user's specific offer), this breakage of the offerredemption may be determined from the data. In some embodiments, thelocations of redemption initiations, the locations of successfulredemptions, and the locations of merchant transactions may be used inthe determination of a redemption success rate (e.g., such thatinitiations, redemptions, and transactions occurring within a specificgeographic area are used to determine redemption breakage).

Additionally, in some embodiments the redemption success rate for anoffer may be compared to a standard or predicted redemption success rateto determine whether the offer may have significant redemption breakage.Moreover, in some embodiments the process 1700 described above may beexecuted for multiple offers to identify offers (as opposed tomerchants) having redemption breakage above a redemption breakagethreshold, or redemption breakage may be offer-specific andmerchant-specific. In some embodiments, a historical redemption successrate may be used, in combination with the number of redemptioninitiations over a given time period, to estimate the number of offersthat have been redeemed over the given time period.

FIG. 18 is a diagram that illustrates an exemplary computing system 1800in accordance with embodiments of the present technique. Variousportions of systems and methods described herein, may include or beexecuted on one or more computer systems similar to computing system1800. Further, processes and modules described herein may be executed byone or more processing systems similar to that of computing system 1800.

Computing system 1800 may include one or more processors (e.g.,processors 1802 a-1802 n) coupled to system memory 1804, an input/outputI/O device interface 1808, and a network interface 1810 via aninput/output (I/O) interface 1812. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1800. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1804). Computing system 1800 may be a uni-processor systemincluding one processor (e.g., processor 1802 a), or a multi-processorsystem including any number of suitable processors (e.g., 1802 a-1802n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1800may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1808 may provide an interface for connection of oneor more I/O devices 1814 to computer system 1800. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1814 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1814 may be connected to computer system 1800through a wired or wireless connection. I/O devices 1814 may beconnected to computer system 1800 from a remote location. I/O devices1814 located on remote computer system, for example, may be connected tocomputer system 1800 via a network and network interface 1810.

Network interface 1810 may include a network adapter that provides forconnection of computer system 1800 to a network. Network interface may1810 may facilitate data exchange between computer system 1800 and otherdevices connected to the network. Network interface 1810 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1804 may be configured to store program instructions 1180or data 1820. Program instructions 1818 may be executable by a processor(e.g., one or more of processors 1802 a-1802 n) to implement one or moreembodiments of the present techniques. Instructions 1818 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1804 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or thelike. System memory 1804 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1802 a-1802 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1804) may include asingle memory device and/or a plurality of memory devices (e.g.,distributed memory devices).

I/O interface 1812 may be configured to coordinate I/O traffic betweenprocessors 1802 a-1802 n, system memory 1804, network interface 1810,I/O devices 1814, and/or other peripheral devices. I/O interface 1812may perform protocol, timing, or other data transformations to convertdata signals from one component (e.g., system memory 1804) into a formatsuitable for use by another component (e.g., processors 1802 a-1802 n).I/O interface 1812 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1800 or multiple computer systems1800 configured to host different portions or instances of embodiments.Multiple computer systems 1800 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1800 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1800 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1800 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1800 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1800 may be transmitted to computer system1800 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present invention may be practiced with othercomputer system configurations.

It should be understood that the description and the drawings are notintended to limit the invention to the particular form disclosed, but tothe contrary, the intention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of the presentinvention as defined by the appended claims. Further modifications andalternative embodiments of various aspects of the invention will beapparent to those skilled in the art in view of this description.Accordingly, this description and the drawings are to be construed asillustrative only and are for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as examples of embodiments. Elements and materials maybe substituted for those illustrated and described herein, parts andprocesses may be reversed or omitted, and certain features of theinvention may be utilized independently, all as would be apparent to oneskilled in the art after having the benefit of this description of theinvention. Changes may be made in the elements described herein withoutdeparting from the spirit and scope of the invention as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.

The present techniques will be better understood when considered in viewof the following enumerated embodiments:

1. An affiliate-network system configured to act as an intermediarybetween merchants issuing coupons or other offers and publisherspromoting the offers to consumers, the affiliate-network system beingconfigured to distribute and track usage of both on-line offers andin-store offers, the system comprising: one or more processors;non-transitory tangible computer-readable memory storing instructionsthat when executed by one or more of the one or more processorseffectuate operations comprising: obtaining a coupon issued by amerchant, the coupon being redeemable in-store at a physical location ofthe merchant; obtaining one or more merchant location identifiers, thecoupon only being redeemable at one or more merchant locationsidentified by the one or more merchant location identifiers; and sendingthe coupon and the merchant location identifiers to publishers forpresentation to consumers by the publishers on user devices of theconsumers.2. The affiliate-network system of embodiment 1, comprising: after anindication that a given consumer has selected an in-store redemptionoffer, effectuating operations comprising: sending the given consumerredemption data documenting that the given consumer is in possession ofthe coupon for presentation to the merchant at the one or more merchantlocations, the data identifying a first publisher that presented thecoupon to the given consumer to credit first publisher.3. The affiliate-network system of embodiment 2, comprising: after theindication that a given consumer has selected an in-store redemptionoffer, effectuating operations further comprising: receiving transactiondata from the merchant indicating that the given consumer redeemed thecoupon at a select merchant location of the one or more merchantlocations; and determining compensation for the first publisher based onthe transaction data.4. The affiliate-network system of any of embodiments 1-3, wherein:sending the coupon to the given publisher comprises sending apublisher-and-coupon specific uniform resource identifier (URI) of thecoupon and the publisher, the URI including the merchant locationidentifiers.5. The affiliate-network system of any of embodiments 1-4, wherein thein-store redemption option includes an option to print the coupon, anoption to send a network address of a presentation of the coupon viatext message, and an option to email a network address of a presentationof the coupon.6. The affiliate network system of any of embodiments 1-5, whereinsending the coupon to publishers comprises: receiving a request from apublisher for coupons, the request including location criteria;determining that one or more merchant locations associated with thecoupon match the location criteria; and in response to thedetermination, sending the coupon to the publisher from which therequest was received.7. The affiliate-network system of embodiment 6, wherein the locationcriteria comprise a geographic area defined by a radius around alocation of the consumer user device.8. The affiliate-network system of embodiment 6, the memory storinginstructions that when executed by one or more of the one or moreprocessors effectuate operations comprising: receiving, from themerchant, a plurality of merchant locations; determining a merchantlocation identifier for each of the plurality of merchant locations; andstoring the merchant location identifiers in a merchant data store.9. The affiliate-network system of embodiment 8, wherein the merchantlocation identifier comprises geographic coordinates.10. The affiliate-network system of embodiment 8, comprising receiving,from the merchant, location attributes for one of the plurality ofmerchant locations.11. A method, comprising: obtaining a plurality of offers frommerchants, the offers including offer location data, the offer locationdata comprising one or more merchant locations, one or more designatedmarket areas, or a combination thereof; determining a first set of theplurality of offers responsive to a request from a publisher andlocation criteria; sending information about the offers to a publisherin response to the request, the information including the offer locationdata; tracking, with one or more processors, usage of the offers byconsumers; allocating credit for usage of the offers by consumers to thepublisher based on the tracking; and sending information about theallocation of credit to merchants and the publisher.12. The method of embodiment 11, wherein the location criteria comprisesa geographic area or a designated market area.13. The method of any of embodiments 11-12, wherein the offer locationdata further comprises a distance threshold defining a permissibledistance from a location.14. The method of any of embodiments 11-13, wherein sending informationabout the offers to a plurality of publishers comprises: for each offer,sending the publisher information specifying a respective uniformresource identifier (URI) of the respective offer, such that thepublisher has a publisher-specific URI for each offer to be included incontent provided by the publisher to consumers, the publisher-specificURI including the offer location data.15. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by a data processing apparatus cause thedata processing apparatus to effectuate operations comprising: obtaininga plurality of offers from merchants, the offers including offerlocation data, the offer location data comprising one or more merchantlocations, one or more designated market areas, or a combinationthereof; determining a first set of the plurality of offers responsiveto a request from a publisher and location criteria; sending informationabout the offers to a publisher in response to the request, theinformation including the offer location data; tracking, with one ormore processors, usage of the offers by consumers; allocating credit forusage of the offers by consumers to the publisher based on the tracking;and sending information about the allocation of credit to merchants andthe publisher.16. A method, comprising: obtaining a location of a consumer userdevice; determining location criteria based on the location of theconsumer user device; sending a request for offers and the locationcriteria to an affiliate-network system; obtaining a set of offers andoffer location data responsive to the request and the location criteria;and sending a plurality of uniform resource identifiers (URI's)corresponding to the set of offers to the consumer user device inresponse to request.17. The method of embodiment 16, wherein the location criteria comprisesa geographic area or a designated market area.18. The method of any of embodiments 16-17, wherein the geographic areais defined by a geographic radius around the consumer user devicelocation.19. The method of any of embodiments 16-18, comprising, prior todetermining location criteria based on the location of the consumer userdevice, receiving a request for offers from the consumer user device20. The method of any of embodiments 16-19, comprising, prior todetermining location criteria based on the location of the consumer userdevice, initiating an offer push to the consumer user device.21. The method of any of embodiments 16-20, wherein the offer locationdata comprises a merchant location associated with each respectiveoffer, the merchant location identifying where the offer is redeemable.22. The method of any of embodiments 16-21, wherein the offer locationdata comprises a designated market area associated with each respectiveoffer.23. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by a data processing apparatus cause thedata processing apparatus to effectuate operations comprising: obtaininga location of a consumer user device; determining location criteriabased on the location of the consumer user device; sending a request foroffers and the location criteria to an affiliate-network system;obtaining a set of offers and offer location data responsive to therequest and the location criteria; and sending a plurality of uniformresource identifiers (URI's) corresponding to the set of offers to theconsumer user device in response to request.

What is claimed is:
 1. An affiliate-network system configured to act asan intermediary between merchants issuing coupons or other offers andpublishers promoting the offers to consumers, the affiliate-networksystem being configured to distribute and track usage of both on-lineoffers and in-store offers, the system comprising: one or moreprocessors; non-transitory tangible computer-readable memory storinginstructions that when executed by one or more of the one or moreprocessors effectuate operations comprising: obtaining a coupon issuedby a merchant, the coupon being redeemable in-store at a physicallocation of the merchant; obtaining one or more merchant locationidentifiers, the coupon only being redeemable at one or more merchantlocations identified by the one or more merchant location identifiers;and sending the coupon and the merchant location identifiers topublishers for presentation to consumers by the publishers on userdevices of the consumers.
 2. The affiliate-network system of claim 1,comprising: after an indication that a given consumer has selected anin-store redemption offer, effectuating operations comprising: sendingthe given consumer redemption data documenting that the given consumeris in possession of the coupon for presentation to the merchant at theone or more merchant locations, the data identifying a first publisherthat presented the coupon to the given consumer to credit firstpublisher.
 3. The affiliate-network system of claim 2, comprising: afterthe indication that a given consumer has selected an in-store redemptionoffer, effectuating operations further comprising: receiving transactiondata from the merchant indicating that the given consumer redeemed thecoupon at a select merchant location of the one or more merchantlocations; and determining compensation for the first publisher based onthe transaction data.
 4. The affiliate-network system of claim 1,wherein: sending the coupon to the given publisher comprises sending apublisher-and-coupon specific uniform resource identifier (URI) of thecoupon and the publisher, the URI including the merchant locationidentifiers.
 5. The affiliate-network system of claim 1, wherein thein-store redemption option includes an option to print the coupon, anoption to send a network address of a presentation of the coupon viatext message, and an option to email a network address of a presentationof the coupon.
 6. The affiliate network system of claim 1, whereinsending the coupon to publishers comprises: receiving a request from apublisher for coupons, the request including location criteria;determining that one or more merchant locations associated with thecoupon match the location criteria; and in response to thedetermination, sending the coupon to the publisher from which therequest was received.
 7. The affiliate-network system of claim 6,wherein the location criteria comprise a geographic area defined by aradius around a location of the consumer user device.
 8. Theaffiliate-network system of claim 6, the memory storing instructionsthat when executed by one or more of the one or more processorseffectuate operations comprising: receiving, from the merchant, aplurality of merchant locations determining a merchant locationidentifier for each of the plurality of merchant locations; and storingthe merchant location identifiers in a merchant data store.
 9. Theaffiliate-network system of claim 8, wherein the merchant locationidentifier comprises geographic coordinates.
 10. The affiliate-networksystem of claim 8, comprising receiving, from the merchant, locationattributes for one of the plurality of merchant locations.
 11. A method,comprising: obtaining a plurality of offers from merchants, the offersincluding offer location data, the offer location data comprising one ormore merchant locations, one or more designated market areas, or acombination thereof; determining a first set of the plurality of offersresponsive to a request from a publisher and location criteria; sendinginformation about the offers to a publisher in response to the request,the information including the offer location data; tracking, with one ormore processors, usage of the offers by consumers; allocating credit forusage of the offers by consumers to the publisher based on the tracking;and sending information about the allocation of credit to merchants andthe publisher.
 12. The method of claim 11, wherein the location criteriacomprises a geographic area or a designated market area.
 13. The methodof claim 11, wherein the offer location data further comprises adistance threshold defining a permissible distance from a location. 14.The method of claim 11, wherein sending information about the offers toa plurality of publishers comprises: for each offer, sending thepublisher information specifying a respective uniform resourceidentifier (URI) of the respective offer, such that the publisher has apublisher-specific URI for each offer to be included in content providedby the publisher to consumers, the publisher-specific URI including theoffer location data.
 15. A tangible, non-transitory, machine-readablemedium storing instructions that when executed by a data processingapparatus cause the data processing apparatus to effectuate operationscomprising: obtaining a plurality of offers from merchants, the offersincluding offer location data, the offer location data comprising one ormore merchant locations, one or more designated market areas, or acombination thereof; determining a first set of the plurality of offersresponsive to a request from a publisher and location criteria; sendinginformation about the offers to a publisher in response to the request,the information including the offer location data; tracking, with one ormore processors, usage of the offers by consumers; allocating credit forusage of the offers by consumers to the publisher based on the tracking;and sending information about the allocation of credit to merchants andthe publisher.
 16. A method, comprising: obtaining a location of aconsumer user device; determining location criteria based on thelocation of the consumer user device; sending a request for offers andthe location criteria to an affiliate-network system; obtaining a set ofoffers and offer location data responsive to the request and thelocation criteria; and sending a plurality of uniform resourceidentifiers (URI's) corresponding to the set of offers to the consumeruser device in response to request.
 17. The method of claim 16, whereinthe location criteria comprises a geographic area or a designated marketarea.
 18. The method of claim 16, wherein the geographic area is definedby a geographic radius around the consumer user device location.
 19. Themethod of claim 16, comprising, prior to determining location criteriabased on the location of the consumer user device, receiving a requestfor offers from the consumer user device
 20. The method of claim 16,comprising, prior to determining location criteria based on the locationof the consumer user device, initiating an offer push to the consumeruser device.
 21. The method of claim 16, wherein the offer location datacomprises a merchant location associated with each respective offer, themerchant location identifying where the offer is redeemable.
 22. Themethod of claim 16, wherein the offer location data comprises adesignated market area associated with each respective offer.
 23. Atangible, non-transitory, machine-readable medium storing instructionsthat when executed by a data processing apparatus cause the dataprocessing apparatus to effectuate operations comprising: obtaining alocation of a consumer user device; determining location criteria basedon the location of the consumer user device; sending a request foroffers and the location criteria to an affiliate-network system;obtaining a set of offers and offer location data responsive to therequest and the location criteria; and sending a plurality of uniformresource identifiers (URI's) corresponding to the set of offers to theconsumer user device in response to request.